From report at bugs.python.org Mon Dec 1 01:12:05 2008 From: report at bugs.python.org (Guilherme Polo) Date: Mon, 01 Dec 2008 00:12:05 +0000 Subject: [issue4475] More verbose error message for Py_FindMethod In-Reply-To: <1228074932.76.0.882771479125.issue4475@psf.upfronthosting.co.za> Message-ID: <1228090325.89.0.528118978684.issue4475@psf.upfronthosting.co.za> Guilherme Polo added the comment: Yes, it was a mistake to set the version for py3k too, that is why I removed after noticing it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 01:32:52 2008 From: report at bugs.python.org (Michael Aivazis) Date: Mon, 01 Dec 2008 00:32:52 +0000 Subject: [issue4476] compileall.py fails if current dir has a "types" subdir with 3.0 (ok with 2.5) Message-ID: <1228091572.68.0.434526872753.issue4476@psf.upfronthosting.co.za> Changes by Michael Aivazis : ---------- components: Library (Lib) nosy: aivazis severity: normal status: open title: compileall.py fails if current dir has a "types" subdir with 3.0 (ok with 2.5) type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 05:33:26 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 01 Dec 2008 04:33:26 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin : Tracing support shows up fairly heavily an a Python profile, even though it's nearly always turned off. The attached patch against the trunk speeds up PyBench by 2% for me. All tests pass. I have 2 questions: 1) Can other people corroborate this speedup on their machines? I'm running on a Macbook Pro (Intel Core2 processor, probably Merom) with a 32-bit build from Apple's gcc-4.0.1. (Apple's gcc consistently produces a faster python than gcc-4.3.) 2) Assuming this speeds things up for most people, should I check it in anywhere besides the trunk? I assume it's out for 3.0; is it in for 2.6.1 or 3.0.1? Pybench output: ------------------------------------------------------------------------------- PYBENCH 2.0 ------------------------------------------------------------------------------- * using CPython 2.7a0 (trunk:67458M, Nov 30 2008, 17:14:10) [GCC 4.0.1 (Apple Inc. build 5488)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.time ------------------------------------------------------------------------------- Benchmark: pybench.out ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/trunk-fast-tracing/build/python.exe Version: 2.7.0 Compiler: GCC 4.0.1 (Apple Inc. build 5488) Bits: 32bit Build: Nov 30 2008 17:14:10 (#trunk:67458M) Unicode: UCS2 ------------------------------------------------------------------------------- Comparing with: ../build_orig/pybench.out ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/trunk-fast-tracing/build_orig/python.exe Version: 2.7.0 Compiler: GCC 4.0.1 (Apple Inc. build 5488) Bits: 32bit Build: Nov 30 2008 13:51:09 (#trunk:67458) Unicode: UCS2 Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 127ms 130ms -2.4% 129ms 132ms -2.1% BuiltinMethodLookup: 90ms 93ms -3.2% 91ms 94ms -3.1% CompareFloats: 88ms 91ms -3.3% 89ms 93ms -4.3% CompareFloatsIntegers: 97ms 99ms -2.1% 97ms 100ms -2.4% CompareIntegers: 79ms 82ms -4.2% 79ms 85ms -6.1% CompareInternedStrings: 90ms 92ms -2.4% 94ms 94ms -0.9% CompareLongs: 86ms 83ms +3.6% 87ms 84ms +3.5% CompareStrings: 80ms 82ms -3.1% 81ms 83ms -2.3% CompareUnicode: 103ms 105ms -2.3% 106ms 108ms -1.5% ComplexPythonFunctionCalls: 139ms 137ms +1.3% 140ms 139ms +0.1% ConcatStrings: 142ms 151ms -6.0% 156ms 154ms +1.1% ConcatUnicode: 87ms 92ms -5.4% 89ms 94ms -5.7% CreateInstances: 142ms 144ms -1.4% 144ms 145ms -1.1% CreateNewInstances: 107ms 109ms -2.3% 108ms 111ms -2.1% CreateStringsWithConcat: 114ms 137ms -17.1% 117ms 139ms -16.0% CreateUnicodeWithConcat: 92ms 101ms -9.2% 95ms 102ms -7.2% DictCreation: 77ms 81ms -4.4% 80ms 85ms -5.9% DictWithFloatKeys: 91ms 107ms -14.5% 93ms 109ms -14.6% DictWithIntegerKeys: 95ms 94ms +1.4% 108ms 96ms +12.3% DictWithStringKeys: 83ms 88ms -5.8% 84ms 88ms -4.7% ForLoops: 72ms 72ms -0.1% 79ms 74ms +5.8% IfThenElse: 83ms 80ms +3.9% 85ms 80ms +5.3% ListSlicing: 117ms 118ms -0.7% 118ms 121ms -1.8% NestedForLoops: 116ms 119ms -2.4% 121ms 121ms +0.0% NormalClassAttribute: 106ms 115ms -7.7% 108ms 117ms -7.7% NormalInstanceAttribute: 96ms 98ms -2.3% 97ms 100ms -3.1% PythonFunctionCalls: 92ms 95ms -3.7% 94ms 99ms -5.2% PythonMethodCalls: 147ms 147ms +0.1% 152ms 149ms +2.1% Recursion: 135ms 136ms -0.3% 140ms 144ms -2.9% SecondImport: 101ms 99ms +2.1% 103ms 101ms +2.2% SecondPackageImport: 107ms 103ms +3.5% 108ms 104ms +3.3% SecondSubmoduleImport: 134ms 134ms +0.3% 136ms 136ms -0.0% SimpleComplexArithmetic: 105ms 111ms -5.0% 110ms 112ms -1.4% SimpleDictManipulation: 95ms 106ms -10.6% 96ms 109ms -12.0% SimpleFloatArithmetic: 90ms 99ms -9.3% 93ms 102ms -8.2% SimpleIntFloatArithmetic: 78ms 76ms +2.3% 79ms 77ms +2.0% SimpleIntegerArithmetic: 78ms 77ms +1.8% 79ms 77ms +2.0% SimpleListManipulation: 80ms 78ms +2.4% 80ms 79ms +1.9% SimpleLongArithmetic: 110ms 113ms -2.0% 111ms 113ms -2.1% SmallLists: 128ms 117ms +9.5% 130ms 124ms +4.9% SmallTuples: 115ms 114ms +1.7% 117ms 114ms +2.2% SpecialClassAttribute: 101ms 112ms -10.3% 104ms 114ms -8.9% SpecialInstanceAttribute: 173ms 177ms -1.9% 176ms 179ms -1.6% StringMappings: 165ms 167ms -1.2% 168ms 169ms -0.5% StringPredicates: 126ms 134ms -5.7% 127ms 134ms -5.6% StringSlicing: 125ms 123ms +1.9% 131ms 130ms +0.7% TryExcept: 79ms 80ms -0.6% 80ms 80ms -0.8% TryFinally: 110ms 107ms +3.0% 111ms 112ms -1.1% TryRaiseExcept: 99ms 101ms -1.6% 100ms 102ms -1.7% TupleSlicing: 127ms 127ms +0.6% 137ms 137ms +0.0% UnicodeMappings: 144ms 144ms -0.3% 145ms 145ms -0.4% UnicodePredicates: 116ms 114ms +1.3% 117ms 115ms +1.1% UnicodeProperties: 106ms 102ms +3.6% 107ms 104ms +3.1% UnicodeSlicing: 95ms 111ms -14.0% 99ms 112ms -11.8% WithFinally: 157ms 152ms +3.3% 159ms 154ms +3.3% WithRaiseExcept: 123ms 125ms -1.1% 125ms 126ms -1.2% ------------------------------------------------------------------------------- Totals: 6043ms 6182ms -2.2% 6185ms 6301ms -1.9% (this=pybench.out, other=../build_orig/pybench.out) 2to3 times: Before: $ time ./python.exe ~/src/2to3/2to3 -f all ~/src/2to3/ >/dev/null real 0m56.685s user 0m55.620s sys 0m0.380s After: $ time ./python.exe ~/src/2to3/2to3 -f all ~/src/2to3/ >/dev/null real 0m55.067s user 0m53.843s sys 0m0.376s == 3% faster Gory details: The meat of the patch is: @@ -884,11 +891,12 @@ fast_next_opcode: f->f_lasti = INSTR_OFFSET(); /* line-by-line tracing support */ - if (tstate->c_tracefunc != NULL && !tstate->tracing) { + if (_Py_TracingPossible && + tstate->c_tracefunc != NULL && !tstate->tracing) { This converts the generated assembly (produced with `gcc -S -dA ...`, then manually annotated a bit) from: # basic block 17 # ../Python/ceval.c:885 LM541: movl 8(%ebp), %ecx LVL319: subl -316(%ebp), %edx movl %edx, 60(%ecx) # ../Python/ceval.c:889 LM542: # %esi = tstate movl -336(%ebp), %esi LVL320: # %eax = tstate->c_tracefunc movl 28(%esi), %eax LVL321: # if tstate->c_tracefunc == 0 testl %eax, %eax # goto past-if () je L567 # more if conditions here to: # basic block 17 # ../Python/ceval.c:889 LM542: movl 8(%ebp), %ecx LVL319: subl -316(%ebp), %edx movl %edx, 60(%ecx) # ../Python/ceval.c:893 LM543: # %eax = _Py_TracingPossible movl __Py_TracingPossible-"L00000000033$pb"(%ebx), %eax LVL320: # if _Py_TracingPossible != 0 testl %eax, %eax # goto rest-of-if (nearby) jne L2321 # opcode = NEXTOP(); continues here The branch should be predicted accurately either way, so there are 2 things that may be contributing to the performance change. First, adding the global caching variable halves the amount of memory that has to be read to check the prediction. The memory that is read is still read one instruction before it's used, but adding a local variable to read the memory earlier doesn't affect the performance. Without the global variable, the compiler puts the tracing code immediately after the if; with the global, it moves it away and puts the non-tracing code immediately after the first test in the if. This may affect branch prediction and may affect the icache. I tried using gcc's __builtin_expect() to ensure that the tracing code is always out-of-line. This moved it much farther away and cost about 1% in performance (i.e. 1% instead of 2% faster than "before"). I don't know why the __builtin_expect() version would be slower. If anyone feels inspired to test this out on another processor or compiler version, let me know how it goes. Jeffrey ---------- components: Interpreter Core files: fast-tracing.diff keywords: needs review, patch messages: 76672 nosy: jyasskin priority: normal severity: normal stage: patch review status: open title: Speed up PyEval_EvalFrameEx when tracing is off. type: performance versions: Python 2.7 Added file: http://bugs.python.org/file12177/fast-tracing.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 05:38:38 2008 From: report at bugs.python.org (steve21) Date: Mon, 01 Dec 2008 04:38:38 +0000 Subject: [issue4478] shutil.copyfile documentation In-Reply-To: <1228106318.66.0.677132442112.issue4478@psf.upfronthosting.co.za> Message-ID: <1228106318.66.0.677132442112.issue4478@psf.upfronthosting.co.za> New submission from steve21 : $ python3.0 Python 3.0rc3 (r30rc3:67312, Nov 22 2008, 21:38:46) >>> import shutil >>> shutil.copyfile('/tmp/f', '/tmp/f') Traceback (most recent call last): File "", line 1, in File "/a/lib/python3.0/shutil.py", line 47, in copyfile raise Error("`%s` and `%s` are the same file" % (src, dst)) shutil.Error: `/tmp/f` and `/tmp/f` are the same file The Python 3 docs at http://docs.python.org/dev/3.0/library/shutil.html#module-shutil mention that copyfile can raise IOError, but they omit to mention that copyfile can also raise shutil.Error. Also, just out of interest, I notice that Sphinx now supports the ':raises:' field. Are there any plans for the Python documentation to start using it? ---------- assignee: georg.brandl components: Documentation messages: 76673 nosy: georg.brandl, steve21 severity: normal status: open title: shutil.copyfile documentation versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 05:39:44 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 01 Dec 2008 04:39:44 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228106384.13.0.61747774103.issue4477@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 05:39:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 01 Dec 2008 04:39:52 +0000 Subject: [issue4073] distutils build_scripts and install_data commands need 2to3 support In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za> Message-ID: <1228106392.82.0.521387502879.issue4073@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Committed as r67464. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 05:53:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 01 Dec 2008 04:53:13 +0000 Subject: [issue4365] Add CRT version info in msvcrt module In-Reply-To: <1227196544.3.0.848395658418.issue4365@psf.upfronthosting.co.za> Message-ID: <1228107193.9.0.66312611829.issue4365@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Merged into 2.6 as r67466, Benjamin had already merged it for 3k as r67461. ---------- status: open -> closed versions: -Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 06:06:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 01 Dec 2008 05:06:14 +0000 Subject: [issue4476] compileall.py fails if current dir has a "types" subdir with 3.0 (ok with 2.5) In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za> Message-ID: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za> New submission from Martin v. L?wis : I can't reproduce that: /tmp/h$ echo "pass" > x.py /tmp/h$ mkdir types :/tmp/h$ /tmp/py3/bin/python3.0 -mcompileall . Listing . ... Listing ./types ... Compiling ./x.py ... /tmp/h$ ls types x.py x.pyc ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 06:08:35 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 01 Dec 2008 05:08:35 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228108115.44.0.606599554277.issue4477@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't think anything performance-related should be checked in before 3.0. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 06:12:26 2008 From: report at bugs.python.org (Michael Aivazis) Date: Mon, 01 Dec 2008 05:12:26 +0000 Subject: [issue4476] compileall.py fails if current dir has a "types" subdir with 3.0 (ok with 2.5) In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za> Message-ID: <1228108346.3.0.577428768734.issue4476@psf.upfronthosting.co.za> Michael Aivazis added the comment: sorry for the sloppy report. add a __init__.py in the types subdir. you should get a "Could not import runpy module" error. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 09:33:09 2008 From: report at bugs.python.org (Hatem) Date: Mon, 01 Dec 2008 08:33:09 +0000 Subject: [issue4479] True division is not smart -> proposing smart True division In-Reply-To: <1228120389.76.0.53863896637.issue4479@psf.upfronthosting.co.za> Message-ID: <1228120389.76.0.53863896637.issue4479@psf.upfronthosting.co.za> New submission from Hatem : A division which results in int, does not produce int ?!? Here is the test case. from __future__ import division assert(isinstance(2 / 1, int)) ---------- components: Interpreter Core messages: 76679 nosy: nassrat severity: normal status: open title: True division is not smart -> proposing smart True division type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:05:44 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 01 Dec 2008 09:05:44 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg : Now that #4389 is fixed, it would be nice if the bdist_msi and bdist_wininst created installers could use the same Python icon for their uninstallers. Note that both commands create installers that are prefixed with the Python version, so there already is a tight binding between the Python interpreter itself and the extensions installed using those installers. Alternatively, perhaps we could add a way to set the icon via command options. ---------- components: Distutils messages: 76680 nosy: lemburg severity: normal status: open title: bdist_msi and bdist_wininst are missing an uninstaller icon versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:06:00 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 01 Dec 2008 09:06:00 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228122360.64.0.666947146507.issue4480@psf.upfronthosting.co.za> Changes by Marc-Andre Lemburg : ---------- type: -> feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:06:50 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 01 Dec 2008 09:06:50 +0000 Subject: [issue4389] Uninstaller Lacks an Icon In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za> Message-ID: <1228122410.49.0.188092198562.issue4389@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I opened #4480 for the distutils commands. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:39:26 2008 From: report at bugs.python.org (Eric Devolder) Date: Mon, 01 Dec 2008 09:39:26 +0000 Subject: [issue4407] Windows Installer Error 1722 when opting for compilation at install time In-Reply-To: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za> Message-ID: <1228124366.81.0.532784061498.issue4407@psf.upfronthosting.co.za> Changes by Eric Devolder : Removed file: http://bugs.python.org/file12176/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:13:04 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 01 Dec 2008 10:13:04 +0000 Subject: [issue4336] Fix performance issues in xmlrpclib In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> Message-ID: <1228126384.66.0.0102102872288.issue4336@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Really? Works for me. Here is a simple patch where we leave the read buffering. passes test_xmlrpclib.py and test_httplib.py Added file: http://bugs.python.org/file12178/xmlrpc_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:27:29 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 01 Dec 2008 10:27:29 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228127249.6.0.168132103963.issue4477@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:32:02 2008 From: report at bugs.python.org (Simon Cross) Date: Mon, 01 Dec 2008 10:32:02 +0000 Subject: [issue4336] Fix performance issues in xmlrpclib In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> Message-ID: <1228127522.59.0.294700645491.issue4336@psf.upfronthosting.co.za> Changes by Simon Cross : ---------- nosy: +hodgestar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:40:13 2008 From: report at bugs.python.org (Senthil) Date: Mon, 01 Dec 2008 10:40:13 +0000 Subject: [issue1208304] urllib2's urlopen() method causes a memory leak Message-ID: <20081201104002.GB9698@goofy> Senthil added the comment: > Amaury Forgeot d'Arc added the comment: > > Reopening: I reproduce the problem consistently with both 2.6 and trunk > versions (not with python 3.0), on Windows XP. > I think this bug is ONLY with respect to Windows Systems. I not able to reproduce this on the current trunk on Linux Ubuntu ( 8.04). I tried 100 and 1000 instances of open and close and everytime file descriptors goes through ESTABLISHED, SYNC_SENT and closes for TCP connections. And yeah, certain instances showed 'can't identify protocol' randomly. But thats a different issue. The original bug raised for Python 2.4 was originally raised on Linux and it seems to have been fixed. A Windows expert should comment on this, if this is consistently reproducable on Windows. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:53:23 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 01 Dec 2008 10:53:23 +0000 Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only) In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za> Message-ID: <1228128803.71.0.0959970770666.issue4474@psf.upfronthosting.co.za> Mark Dickinson added the comment: Just to be clear, the defect in PyUnicode_FromWideChar is present both in Python 2.x and Python 3.x. The problem with command-line arguments only occurs in Python 3.x, since 2.x doesn't use PyUnicode_FromWideChar in converting arguments. I can reproduce the 'No such file or directory' error on both OS X and Linux, for Python 3.0. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:56:37 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Dec 2008 10:56:37 +0000 Subject: [issue4479] True division is not smart -> proposing smart True division In-Reply-To: <1228120389.76.0.53863896637.issue4479@psf.upfronthosting.co.za> Message-ID: <1228128997.29.0.900682990226.issue4479@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is by design. Having different result types based on the input values would not be "smart" in my book, rather "incredibly fragile". ---------- nosy: +pitrou resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:07:48 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 01 Dec 2008 11:07:48 +0000 Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only) In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za> Message-ID: <1228129668.75.0.583296901319.issue4474@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: This is due to the function downcasting the wchar_t values to Py_UNICODE, which is a 2-byte value if you build Python as UCS2 version on Unix. Most Unixes ship with UCS4 builds, so you don't see the problem there. Mac OS X ships with a UCS2 build, which is why you run into the problem on that platform. UCS2 builds are also the default build on Unix, so if you compile Python yourself, it will result in a UCS2 build, unless you explicitly specify the UCS4 build configure option or configure happens to find a Tcl/Tk version installed that uses UCS4 internally. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:15:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 01 Dec 2008 11:15:26 +0000 Subject: [issue4479] True division is not smart -> proposing smart True division In-Reply-To: <1228120389.76.0.53863896637.issue4479@psf.upfronthosting.co.za> Message-ID: <1228130126.92.0.401248751119.issue4479@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Having different result types based on the input > values would not be "smart" in my book, rather "incredibly fragile". Well, there are precedents: >>> type(2**3) >>> type(2**-3) My initial reaction to this was negative, but I'm struggling to think of situations where it would be bad. I'm also struggling to think of situations where it would be useful. Maybe Monday morning is just a bad time for thinking. :-) Might be worth a discussion on python-ideas, at least? To the OP: you should be aware that getting this accepted into Python would likely be very hard. You'd need at least a PEP explaining clearly the benefits of such a change, a working patch, and strong community support. And even then it might have to wait for Python 4.0. Which Guido has said probably won't happen... ---------- nosy: +marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:43:04 2008 From: report at bugs.python.org (Hatem) Date: Mon, 01 Dec 2008 11:43:04 +0000 Subject: [issue4479] True division is not smart -> proposing smart True division In-Reply-To: <1228130126.92.0.401248751119.issue4479@psf.upfronthosting.co.za> Message-ID: <2238dbfb0812010343x1fe5c0c5q6016234ba54f30b5@mail.gmail.com> Hatem added the comment: On Mon, Dec 1, 2008 at 7:15 AM, Mark Dickinson wrote: > Well, there are precedents: > >>>> type(2**3) > >>>> type(2**-3) > > > My initial reaction to this was negative, but I'm struggling to think of > situations where it would be bad. I'm also struggling to think of > situations where it would be useful. Maybe Monday morning is just a > bad time for thinking. :-) > > Might be worth a discussion on python-ideas, at least? I don't know about the internal representations in python, but I believe ints can be larger than ints. Nevertheless your example there which would have drove me nuts if I found it :-). I like the true division feature, but I find it too far deviant, if all of a sudden code started producing floats instead of ints, on a given upgrade of python someday soon. I think the result should be int if it is an int, but float if and only if it is really needed. I think your right, this conversation should probably move to python ideas, since this was by design and not a bug. (but I do not really like this part of the "feature"). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:45:42 2008 From: report at bugs.python.org (Hatem) Date: Mon, 01 Dec 2008 11:45:42 +0000 Subject: [issue4479] True division is not smart -> proposing smart True division In-Reply-To: <2238dbfb0812010343x1fe5c0c5q6016234ba54f30b5@mail.gmail.com> Message-ID: <2238dbfb0812010345k45bdc7c9k49e7aacb5343e0b6@mail.gmail.com> Hatem added the comment: On Mon, Dec 1, 2008 at 7:43 AM, Hatem Nassrat wrote: > On Mon, Dec 1, 2008 at 7:15 AM, Mark Dickinson wrote: >> Well, there are precedents: >> >>>>> type(2**3) >> >>>>> type(2**-3) >> >> >> My initial reaction to this was negative, but I'm struggling to think of >> situations where it would be bad. I'm also struggling to think of >> situations where it would be useful. Maybe Monday morning is just a >> bad time for thinking. :-) It seems to not be my day either. I think the above behaviour is what I would expect. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 13:01:03 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Dec 2008 12:01:03 +0000 Subject: [issue4479] True division is not smart -> proposing smart True division In-Reply-To: <1228130126.92.0.401248751119.issue4479@psf.upfronthosting.co.za> Message-ID: <1228132850.1350.7.camel@localhost> Antoine Pitrou added the comment: Le lundi 01 d?cembre 2008 ? 11:15 +0000, Mark Dickinson a ?crit : > My initial reaction to this was negative, but I'm struggling to think of > situations where it would be bad. Consider someone who writes: z = y / x return my_list[z] In all his tests, x is a divisor of y and therefore z is an integer, the code runs ok. Suddenly in an use case, x is not a divisor of y, z is therefore a float, and the "return" line raises a TypeError. The reverse can also happen, consider something like : z = y / x return z.as_integer_ratio() As for : >>> type(2**-3) I'd argue it is less annoying because it only depends on the value of the second operand which is, most of the time, a constant, and therefore you know upfront if the result will be a float or an int. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 13:17:24 2008 From: report at bugs.python.org (Hatem) Date: Mon, 01 Dec 2008 12:17:24 +0000 Subject: [issue4479] True division is not smart -> proposing smart True division In-Reply-To: <1228132850.1350.7.camel@localhost> Message-ID: <2238dbfb0812010417m47fdf9e9gc3a53e7d52e877e0@mail.gmail.com> Hatem added the comment: On Mon, Dec 1, 2008 at 8:01 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Le lundi 01 d?cembre 2008 ? 11:15 +0000, Mark Dickinson a ?crit : >> My initial reaction to this was negative, but I'm struggling to think of >> situations where it would be bad. > > Consider someone who writes: > > z = y / x > return my_list[z] > > In all his tests, x is a divisor of y and therefore z is an integer, the > code runs ok. > Suddenly in an use case, x is not a divisor of y, z is therefore a > float, and the "return" line raises a TypeError. That brings me to another point which will make you guys think i'm crazy and close this thread immediately :-). I actually tried that recently (that being using a float as an index), actually used it as a slice. I would think that should work, it should round the float usually, and if used in a slice, if it is an end it should round up, if it is a start round down, for 0.5? Maybe I should write my first PEP and watch it thrown out :-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:52:00 2008 From: report at bugs.python.org (Retro) Date: Mon, 01 Dec 2008 13:52:00 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228139520.52.0.800525399424.issue4480@psf.upfronthosting.co.za> Retro added the comment: Marc-Andre, why haven't you selected the version 'Python 3.0' as well? I think it's still time to fix this for the much-anticipated Python 3.0. The final release is coming soon, but I think it's still time. Martin v. L?wis, please fix this bug for Python 3.0 as well. Appreciate it. Thanks. ---------- nosy: +Retro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:52:13 2008 From: report at bugs.python.org (Retro) Date: Mon, 01 Dec 2008 13:52:13 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228139533.89.0.988149453517.issue4480@psf.upfronthosting.co.za> Changes by Retro : ---------- versions: +Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:53:08 2008 From: report at bugs.python.org (Retro) Date: Mon, 01 Dec 2008 13:53:08 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228139588.68.0.825585025157.issue4480@psf.upfronthosting.co.za> Changes by Retro : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:54:01 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 01 Dec 2008 13:54:01 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228139520.52.0.800525399424.issue4480@psf.upfronthosting.co.za> Message-ID: <4933EC76.7090208@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-01 14:52, Retro wrote: > Retro added the comment: > > Marc-Andre, why haven't you selected the version 'Python 3.0' as well? I > think it's still time to fix this for the much-anticipated Python 3.0. > The final release is coming soon, but I think it's still time. Martin v. > L?wis, please fix this bug for Python 3.0 as well. Appreciate it. Thanks. It's too late for new features in Python 3.0. Those will have to wait until 3.1 gets released. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:56:28 2008 From: report at bugs.python.org (Retro) Date: Mon, 01 Dec 2008 13:56:28 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228139788.21.0.891605754201.issue4480@psf.upfronthosting.co.za> Retro added the comment: Martin, I hope you have the time to fix this. I would very much appreciate this fix. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:58:43 2008 From: report at bugs.python.org (Retro) Date: Mon, 01 Dec 2008 13:58:43 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228139923.68.0.0487962312394.issue4480@psf.upfronthosting.co.za> Retro added the comment: Oh, Python 3.0 is in feature freeze. I see. Too bad. Well, at least we'll have those icons in the next release. When do you think that'll be released? Talking about Python 3.1 of course. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 15:02:10 2008 From: report at bugs.python.org (Nick Barnes) Date: Mon, 01 Dec 2008 14:02:10 +0000 Subject: [issue4426] UTF7 decoding is far too strict In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za> Message-ID: <1228140130.88.0.252207691297.issue4426@psf.upfronthosting.co.za> Nick Barnes added the comment: My original defect report here was incorrect, or possibly only relates to a particular older Python installation. It is still the case that UTF-7 decoding is fussier than it need be (decoding should be permissive), and is broken specifically for the '/' character (ASCII 47). I'm probably going to rewrite the whole codec for greater clarity and decoding permissiveness. Any UTF-7 encoder has two boolean parameters: whether to base-64 encode whitespace (sp, ht, nl, cr), and whether to base-64 encode "set O" characters. The existing Python UTF-7 encoder says "no" to both of these. It would be useful to have them as options. How should encoding parameters such as these be passed? As setstate() methods on the IncrementalEncoder and StreamWriter objects? Or should I provide four separate codecs (retaining the existing behaviour in the 'utf7' codec, of course). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 16:26:21 2008 From: report at bugs.python.org (Jeremy Hylton) Date: Mon, 01 Dec 2008 15:26:21 +0000 Subject: [issue4336] Fix performance issues in xmlrpclib In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> Message-ID: <1228145181.16.0.378983382793.issue4336@psf.upfronthosting.co.za> Jeremy Hylton added the comment: I submitted r67442, which combines the headers and body in a single send() call. We should look at the buffering issue now, although I probably won't have any time to check on it until Friday. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 16:45:45 2008 From: report at bugs.python.org (Konam) Date: Mon, 01 Dec 2008 15:45:45 +0000 Subject: [issue4481] Windows installer crash In-Reply-To: <1228146345.67.0.732952109448.issue4481@psf.upfronthosting.co.za> Message-ID: <1228146345.67.0.732952109448.issue4481@psf.upfronthosting.co.za> New submission from Konam : Tried downloading the "Python 2.6 Windows Installer" for Windows Vista 64bit and when I tried installing it, it simply made my Windows Installer stop working. I've tried "Just for me" and the "For everyone" options and it still crashes. I'm wondering, is it the "Python 2.6 Windows AMD64 Installer" I'm supposed to use even if I've got an Intel chip in my computer? ---------- components: Installation messages: 76698 nosy: Konam severity: normal status: open title: Windows installer crash type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 16:57:36 2008 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Mon, 01 Dec 2008 15:57:36 +0000 Subject: [issue3871] cross building python for mingw32 with distutils In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1228147056.9.0.227055345186.issue3871@psf.upfronthosting.co.za> Zooko O'Whielacronx added the comment: I'm interested in this patch so I'm adding myself to the Nosy list. ---------- nosy: +zooko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:12:06 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 01 Dec 2008 16:12:06 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228147926.31.0.272014687029.issue4477@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Martin, does your comment mean you think this should stay out of the trunk(s) until 3.0 is released? That's fine. How about after that: should it go in the 2.6.x and 3.0.x branches too? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:00:05 2008 From: report at bugs.python.org (Akira Kitada) Date: Mon, 01 Dec 2008 17:00:05 +0000 Subject: [issue858809] Use directories from configure rather than hardcoded Message-ID: <1228150805.18.0.183108737484.issue858809@psf.upfronthosting.co.za> Changes by Akira Kitada : ---------- versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:45:17 2008 From: report at bugs.python.org (Guilherme Polo) Date: Mon, 01 Dec 2008 17:45:17 +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: <1228153517.92.0.189591234799.issue1028@psf.upfronthosting.co.za> Guilherme Polo added the comment: Some more clarifications about this bug: Tcl shouldn't be giving us a UTF-8 string with a 0xC0 byte, since that is not valid UTF-8. I'm aware that Tcl uses the sequence 0xC0 0x80 for special purposes but it is also said that such sequences shouldn't be passed as is when exported. This bug doesn't affect python 2.x because it uses PyString_FromString to convert such value to a Python string, where python 3.x uses PyUnicode_FromString which assumes that it is receiving a valid utf-8 string but it turns out that is not always the case here. It is indeed related to tk 8.4, but not sure which ones exactly (I hit it with tk 8.4.19). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:51:07 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 01 Dec 2008 17:51:07 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228153867.59.0.783630100789.issue4480@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Retro: please don't add people to the nosy list. I don't plan to do anything about this issue in the near future, except perhaps to review patches that get contributed (and even that may take many months). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:52:25 2008 From: report at bugs.python.org (Dino Viehland) Date: Mon, 01 Dec 2008 17:52:25 +0000 Subject: [issue4482] 10e667.__format__('+') should return 'inf' In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za> Message-ID: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za> New submission from Dino Viehland : 10e667.__format__('+') returns '+1.0#INF' vs: 10e667.__format__('') which returns 'inf' The docs say 'inf' is right. ---------- messages: 76703 nosy: DinoV severity: normal status: open title: 10e667.__format__('+') should return 'inf' versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:53:49 2008 From: report at bugs.python.org (Dino Viehland) Date: Mon, 01 Dec 2008 17:53:49 +0000 Subject: [issue4482] 10e667.__format__('+') should return 'inf' In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za> Message-ID: <1228154029.2.0.677451136129.issue4482@psf.upfronthosting.co.za> Changes by Dino Viehland : ---------- components: +Interpreter Core type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 19:07:59 2008 From: report at bugs.python.org (Nick Barnes) Date: Mon, 01 Dec 2008 18:07:59 +0000 Subject: [issue4426] UTF7 decoding is far too strict In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za> Message-ID: <1228154879.8.0.989452171224.issue4426@psf.upfronthosting.co.za> Nick Barnes added the comment: Here is my patch. This is a rewrite of the UTF7 encoder and decoder. It now handles surrogate pairs correctly, so non-BMP characters work with this codec. And my motivating example ('/'.decode('utf7')) works OK. I'm not totally confident of the error-handling code here, but in 'strict' mode this is definitely a better codec than the one it replaces. This patch is based on the Python 2.6 distribution. Added file: http://bugs.python.org/file12179/utf7patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 19:16:30 2008 From: report at bugs.python.org (Eric Smith) Date: Mon, 01 Dec 2008 18:16:30 +0000 Subject: [issue4482] 10e667.__format__('+') should return 'inf' In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za> Message-ID: <1228155390.73.0.0545972420702.issue4482@psf.upfronthosting.co.za> Changes by Eric Smith : ---------- assignee: -> eric.smith nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 19:52:07 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 01 Dec 2008 18:52:07 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228157527.29.0.414104937489.issue4477@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think it should stay out of the trunk until 3.0 is released only because that simplifies merging and 3.0 is only 3 days away. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 21:08:53 2008 From: report at bugs.python.org (Retro) Date: Mon, 01 Dec 2008 20:08:53 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za> Message-ID: <1228162133.3.0.833042174197.issue4480@psf.upfronthosting.co.za> Retro added the comment: So you are saying you won't create the icons for bdist_msi and bdist_wininst even for future versions (2.7 and 3.1) of the Python interpreter? ---------- versions: -Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 22:41:14 2008 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 01 Dec 2008 21:41:14 +0000 Subject: [issue858809] Use directories from configure rather than hardcoded Message-ID: <1228167675.0.0.563761288901.issue858809@psf.upfronthosting.co.za> Roumen Petrov added the comment: The complete patch require redesign of python-distutils ;) ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 22:44:05 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 01 Dec 2008 21:44:05 +0000 Subject: [issue4471] IMAP4 missing support for starttls In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za> Message-ID: <1228167845.73.0.510968586811.issue4471@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 22:44:16 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 01 Dec 2008 21:44:16 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228167856.98.0.179086466229.issue4473@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 22:44:46 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 01 Dec 2008 21:44:46 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1228167886.32.0.558789920605.issue4470@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 23:04:30 2008 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 01 Dec 2008 22:04:30 +0000 Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only) In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za> Message-ID: <1228169070.57.0.248102421141.issue4474@psf.upfronthosting.co.za> Roumen Petrov added the comment: Marc-Andre explain all. For the protocol my version is from trunk, python is build with default options. Since system tcl limit UTF-8 to 3 bytes, python is build for UCS-2. In the report output from python is with character 010d(UCS-2). May be issue is not for versions before 3.0. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 23:35:12 2008 From: report at bugs.python.org (Leger) Date: Mon, 01 Dec 2008 22:35:12 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> New submission from Leger : Under Debian/Lenny/i486, I install python3.0rc3. After untar the Python3.0rc3 package, I replace in the configure "/usr/local" by "/usr". After I do : "configure --with-pydebug --with-doc-strings --enable-shared --enable-profiling --enable-ipv6 --with-threads --with-tsc ; make" The result during make is : "Failed to find the necessary bits to build these modules: _dbm To find the necessary bits, look in setup.py in detect_modules() for the module's name." The release of the dbm library is : libgdbm-dev 1.8.3-3 GNU dbm database routines (development files) The header for dbm : "_gdbmmodule.c" request "gdbm.h", and is here "/usr/include/gdbm.h" The "Modules/_dbmmodule.c" use : #include " ... #include ... but I have only "/usr/include/gdbm-ndbm.h" Can you patch the "_dbmmodule.c" to use it ? ---------- components: Extension Modules messages: 76709 nosy: legerf severity: normal status: open title: Error to build _dbm module during make type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 23:45:19 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 01 Dec 2008 22:45:19 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228171519.18.0.30008645575.issue4477@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Before it is accepted, I'd like to see some independent analysis (which I might have to carry out myself). It would also be good if some deeper understanding of the effect could be provided - I'm fairly skeptical that such a minor change should have any notable effect. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 23:49:59 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 01 Dec 2008 22:49:59 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228171799.36.0.975001226129.issue4477@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 on the patch. It makes good sense to me. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 23:59:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 01 Dec 2008 22:59:13 +0000 Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller icon In-Reply-To: <1228162133.3.0.833042174197.issue4480@psf.upfronthosting.co.za> Message-ID: <49346C3E.50906@v.loewis.de> Martin v. L?wis added the comment: > So you are saying you won't create the icons for bdist_msi and > bdist_wininst even for future versions (2.7 and 3.1) of the Python > interpreter? Yes, exactly so. I'm -1 on using the Python icon for that by default, I'm +0 on giving the package a choice of icons (i.e. I could live with it if it is opt-in, but I won't spend time on writing patches in this respect). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:00:08 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Dec 2008 23:00:08 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228172408.83.0.852470038012.issue4473@psf.upfronthosting.co.za> STINNER Victor added the comment: You might split your patch into smaller patches, example: * patch 1: implement CAPA method * patch 2: POP3_SSL refatoring * patch 3: stls() method Comments: - Do you really need to keep a reference to the "raw" socket (self._sock) for a SSL connection? - I don't understand what is sock.shutdown(SHUT_RDWR). When is it needed? Does it change the behaviour? - Could you write a method to parse the capabilities because I hate long lambda function. You may write doctest for the new method :-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:05:56 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Dec 2008 23:05:56 +0000 Subject: [issue4471] IMAP4 missing support for starttls In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za> Message-ID: <1228172756.95.0.162652807784.issue4471@psf.upfronthosting.co.za> STINNER Victor added the comment: Same comments than issue #4473: - you might split your patch into smaller patches - Do you really need to keep a reference to the "raw" socket? - I don't understand what is sock.shutdown(SHUT_RDWR). When is it needed? Does it change the behaviour? Oh, another comment: - When I fixed poplib/imaplib in py3k, I created a _create_socket() method which to factorize the "classic" class and the SSL class. The classic class uses socket.create_connection() which supports IPv4 and IPv6 (and maybe other protocols) whereas the SSL version reimplements create_connection(): "for ... in getaddrinfo...". So you may reuse this idea for in your SSL refactoring (for POP3 and IMAP4). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:07:55 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Dec 2008 23:07:55 +0000 Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only) In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za> Message-ID: <1228172875.19.0.815615136003.issue4474@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:41:42 2008 From: report at bugs.python.org (Weeble) Date: Mon, 01 Dec 2008 23:41:42 +0000 Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes Message-ID: <1228174902.9.0.477315972438.issue1529142@psf.upfronthosting.co.za> Changes by Weeble : Added file: http://bugs.python.org/file12180/IDLE_automatic_ports.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:47:04 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 01 Dec 2008 23:47:04 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za> Message-ID: <1228175224.19.0.652493787191.issue2306@psf.upfronthosting.co.za> Guido van Rossum added the comment: Working on it! Woo hoo! Thanks Victor for the detailed feedback. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:49:22 2008 From: report at bugs.python.org (Weeble) Date: Mon, 01 Dec 2008 23:49:22 +0000 Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes Message-ID: <1228175362.91.0.195751822158.issue1529142@psf.upfronthosting.co.za> Weeble added the comment: Okay, I've uploaded a patch. As suggested, it passes 0 for the port number and the port is automatically assigned. It then extracts the port from the socket and passes it to the subprocess. Note that this means the subprocess inherits the listening socket, which I gather is less than ideal. However, as far as I can tell, this happens anyway if the subprocess is restarted, since the socket remains bound and listening the whole time. The patch also removes the use of SO_REUSEADDR because it is no longer needed. This works without a problem for me on Windows XP, but I can't test it on anything more Unixy. I removed the three retries when it fails to bind a socket - it's not clear when this might fail and yet still be a good idea to retry, but I can put that back if that's something that shouldn't be messed with. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:50:36 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Mon, 01 Dec 2008 23:50:36 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228175436.27.0.454493262242.issue4473@psf.upfronthosting.co.za> Lorenzo M. Catucci added the comment: I understand the need to keep things simple, but this time the split seemed a bit overkill. If needed, I'll redo the patch into a small series. Thinking of it... I was unsure if it really made sense to split out smtp/pop/imap patches instead of sending them all at once... :-) As for the shutdown before close, it's needed to let the server know we are leaving, instead of waiting until socket timeout. This is the reason I need to keep the reference to the wrapped socket. You don't usually configure maildrop servers to limit the number/rate of connects as you do on smtp servers; still, you could get into problems with stateful forewalls or the like. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:02:57 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 00:02:57 +0000 Subject: [issue4471] IMAP4 missing support for starttls In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za> Message-ID: <1228176177.27.0.280843785902.issue4471@psf.upfronthosting.co.za> Lorenzo M. Catucci added the comment: As in #4473: if needed, I'll redo the patch into a small series. I've cut and pasted the following. As for the shutdown before close, it's needed to let the server know we are leaving, instead of waiting until socket timeout. This is the reason I need to keep the reference to the wrapped socket. You don't usually configure maildrop servers to limit the number/rate of connects as you do on smtp servers; still, you could get into problems with stateful firewalls or the like. As for the last comment, I'll gladly look at your changes and try to copy^H^H^H^Hbackport them. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:05:08 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2008 00:05:08 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228176308.9.0.615352990111.issue4473@psf.upfronthosting.co.za> STINNER Victor added the comment: > As for the shutdown before close, it's needed to let the server know > we are leaving, instead of waiting until socket timeout. Extracts of an UNIX FAQ [1]: "Generally the difference between close() and shutdown() is: close() closes the socket id for the process but the connection is still opened if another process shares this socket id." "i have noticed on some (mostly non-unix) operating systems though a close by all processes (threads) is not enough to correctly flush data, (or threads) is not. A shutdown must be done, but on many systems it is superfulous." So shutdown() is useless on most OS, but it looks like it's better to use it ;-) > This is the reason I need to keep the reference to the wrapped socket. You don't need to do that. The wrapper already calls shutdown() of the parent socket (see Lib/ssl.py). [1] http://www.developerweb.net/forum/archive/index.php/t-2940.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:43:14 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 02 Dec 2008 00:43:14 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228178594.84.0.565473885922.issue4483@psf.upfronthosting.co.za> Skip Montanaro added the comment: Patching _dbmmodule.c alone isn't sufficient. At minimum setup.py would have to be adjusted to detect the presence of the odd ndbm.h file. ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:47:14 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 02 Dec 2008 00:47:14 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228178834.24.0.775002519691.issue4483@psf.upfronthosting.co.za> Skip Montanaro added the comment: Can you try the attached patch and let us know if it works for you? ---------- assignee: -> skip.montanaro keywords: +easy, patch Added file: http://bugs.python.org/file12181/dbm.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:56:34 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 02 Dec 2008 00:56:34 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228179394.75.0.845971920056.issue4483@psf.upfronthosting.co.za> Skip Montanaro added the comment: Here's a similarly untested patch for Python 2.x. Can you try it as well? Added file: http://bugs.python.org/file12182/dbm2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 03:06:04 2008 From: report at bugs.python.org (Chris Palmer) Date: Tue, 02 Dec 2008 02:06:04 +0000 Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing Message-ID: <1228183564.17.0.443912207978.issue670664@psf.upfronthosting.co.za> Chris Palmer added the comment: Here is an additional test case. I have a super simple HTML "minifier" that burps when given this test file: ======== $ cat test.html 'foo ' ======== The explosion is: ======== $ ./minify.py test.html Warning: malformed start tag 'foo Traceback (most recent call last): File "./minify.py", line 84, in m.feed(f.read()) File "/usr/local/lib/python2.5/HTMLParser.py", line 108, in feed self.goahead(0) File "/usr/local/lib/python2.5/HTMLParser.py", line 148, in goahead k = self.parse_starttag(i) File "/usr/local/lib/python2.5/HTMLParser.py", line 226, in parse_starttag endpos = self.check_for_whole_start_tag(i) File "/usr/local/lib/python2.5/HTMLParser.py", line 302, in check_for_whole_start_tag raise AssertionError("we should not get here!") AssertionError: we should not get here! ======== ---------- nosy: +cpalmer versions: +Python 2.5 -Python 2.3 Added file: http://bugs.python.org/file12183/minify.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 03:07:42 2008 From: report at bugs.python.org (Chris Palmer) Date: Tue, 02 Dec 2008 02:07:42 +0000 Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing Message-ID: <1228183662.33.0.96889739368.issue670664@psf.upfronthosting.co.za> Changes by Chris Palmer : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 07:00:36 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 02 Dec 2008 06:00:36 +0000 Subject: [issue4387] binascii b2a functions accept strings (unicode) as data In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za> Message-ID: <1228197636.16.0.00981847767511.issue4387@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Committed as r67472. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 07:06:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 02 Dec 2008 06:06:32 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228197992.64.0.903663477949.issue4449@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a documentation bug, not a library bug, right? (unless someone claims that the documentation is right and the library is wrong) So: a) this seems to be a duplicate of issue 3256, and b) it's "just" a documention bug. Not sure why this is marked as release blocker. ---------- components: +Documentation -Library (Lib) nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 07:26:46 2008 From: report at bugs.python.org (Shaddy Baddah) Date: Tue, 02 Dec 2008 06:26:46 +0000 Subject: [issue4484] struct: per item endianess specification In-Reply-To: <1228199205.8.0.509541493061.issue4484@psf.upfronthosting.co.za> Message-ID: <1228199205.8.0.509541493061.issue4484@psf.upfronthosting.co.za> New submission from Shaddy Baddah : I note that using the struct module, a user can specify if number items of the format are to be interpreted as either big or small endian. However the format specifier can only accept one indicator character at its first character to apply for all number items in it. e.g: "HI" where the first '<' character indicates the default endianess (for compatibility purposes) and then the second '>' character indicates that the unsigned short should be interpreted as big endian. The unsigned int defaults to small endian as per the first character. ---------- components: Library (Lib) messages: 76726 nosy: da4an1qu1 severity: normal status: open title: struct: per item endianess specification type: feature request versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:12:19 2008 From: report at bugs.python.org (Thomas Lee) Date: Tue, 02 Dec 2008 07:12:19 +0000 Subject: [issue4347] Dependencies of graminit.h are not rebuilt when the file is regenerated In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1228201939.96.0.820748587182.issue4347@psf.upfronthosting.co.za> Thomas Lee added the comment: A deeper issue here is that Parser/parsetok.c has a dependency on graminit.h. The problem is that Parser/parsetok.c is a part of the Parser/pgen program which is actually being used to *generate* graminit.h in the first place. This breaks Python whenever syntax is added to or removed from Grammar/Grammar in such a way that the value of encoding_decl changes, because the value of encoding_decl used by pgen is different to the value used to build python itself. A simple work around for those wishing to change the syntax is a "make; make clean; make". It'd obviously be nice if the build were fixed, though. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:45:21 2008 From: report at bugs.python.org (Thomas Lee) Date: Tue, 02 Dec 2008 07:45:21 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1228203921.66.0.664648558803.issue4347@psf.upfronthosting.co.za> Thomas Lee added the comment: Here's a new patch that I believe should fix this issue. It modifies Makefile.pre.in to include a few additional dependency declarations for source files that depend on Include/graminit.h and Include/Python-ast.h, as well as moving encoding_decl to the top of Grammar/Grammar. This should ensure that changes to the syntax and/or AST nodes will not cause cryptic errors. Longer term, it would be great to remove the parser's dependency on graminit.h to ensure this sort of problem is never an issue. ---------- title: Dependencies of graminit.h are not rebuilt when the file is regenerated -> Circular dependency causes SystemError when adding new syntax Added file: http://bugs.python.org/file12184/build-evilness-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:46:20 2008 From: report at bugs.python.org (Thomas Lee) Date: Tue, 02 Dec 2008 07:46:20 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1228203980.27.0.153171626654.issue4347@psf.upfronthosting.co.za> Thomas Lee added the comment: I mean pgen's dependency on graminit.h, not the parser's. :) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:59:12 2008 From: report at bugs.python.org (Thomas Lee) Date: Tue, 02 Dec 2008 07:59:12 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1228204752.01.0.741514480026.issue4347@psf.upfronthosting.co.za> Thomas Lee added the comment: okay, so it turns out that putting rules in Grammar/Grammar before the top-level non-terminals breaks things in a different way. Attached is another (hopefully final and working) patch. Added file: http://bugs.python.org/file12185/build-evilness-fix-02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 09:52:00 2008 From: report at bugs.python.org (Glenn Linderman) Date: Tue, 02 Dec 2008 08:52:00 +0000 Subject: [issue4485] fast swap of "default" Windows python versions In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za> Message-ID: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za> New submission from Glenn Linderman : Here's how I set up my computer, for multiple versions. Now to change the "default", I just use the assoc command to change the association for .py to one of the three listed ftypes. Simple and quick. c:\>ftype Python25.File ftype Python25.File Python25.File="C:\Python25\python.exe" "%1" %* c:\>ftype Python26.File ftype Python26.File Python26.File="C:\Python26\python.exe" "%1" %* c:\>ftype Python30.File ftype Python30.File Python30.File="C:\Python30\python.exe" "%1" %* c:\>assoc .py assoc .py .py=Python25.File It would be nice if the ftypes were version specific as created by the installer; IIRC, I created the above three from the ftype Python.File as I installed each version. The Python.File could still be created by default, and could still reflect the last temporally installed version of Python... but by documenting the version specific ftypes, the user could still switch among versions. I suppose there is a question of if the version should contain two or three parts, i.e. Python253.File; and if the version should be separated such as Python2.5.3.File; the above worked for me for the moment, but some thought might reveal a more useful technique. It might even be appropriate for a Python version to create 3 ftypes, such that version N.M.O creates ftypes named PythonN.File, PythonN.M.File, and PythonN.M.O.File. All but the most specific one would be subject to change when additional versions are installed. If M or O are zero, they should probably still be specified (as zero) in a scheme like this, so that there would be a solid way of referring to all the specific versions. ---------- components: Installation messages: 76731 nosy: v+python severity: normal status: open title: fast swap of "default" Windows python versions type: feature request versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 11:33:59 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Dec 2008 10:33:59 +0000 Subject: [issue4486] Exception traceback is incorrect for strange exception handling In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> Message-ID: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> New submission from Nick Coghlan : The interactive interpreter doesn't appear to like it if __cause__ and __context__ are both set on the current exception. ================= >>> try: ... raise IOError ... except: ... raise AttributeError from KeyError ... KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 2, in IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 4, in AttributeError ================= I'm not entirely sure what *should* be displayed here (the code I typed in is admittedly bizarre), but what is currently being displayed definitely isn't right. ---------- components: Interpreter Core messages: 76732 nosy: ncoghlan severity: normal status: open title: Exception traceback is incorrect for strange exception handling versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 11:36:00 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Dec 2008 10:36:00 +0000 Subject: [issue4486] Exception traceback is incorrect for strange exception handling In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> Message-ID: <1228214160.52.0.139734304666.issue4486@psf.upfronthosting.co.za> Nick Coghlan added the comment: Such a bizarre corner case probably isn't an actual release blocker, but I'm setting it as such so that Barry can make that call explicitly before the final 3.0 release. ---------- assignee: -> barry nosy: +barry priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:28:17 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 12:28:17 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228220897.76.0.728236214581.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12186/poplib_01_CAPA.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:28:36 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 12:28:36 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228220916.62.0.42553814203.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12187/poplib_02_sock_shutdown.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:28:53 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 12:28:53 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228220933.01.0.0595407190922.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12188/poplib_03_SSL_refactor.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:29:10 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 12:29:10 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228220950.31.0.869302597259.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12189/poplib_04_STLS.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:29:21 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 12:29:21 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228220961.71.0.962601016733.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Removed file: http://bugs.python.org/file12170/poplib.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:31:59 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 12:31:59 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228221119.77.0.729094845616.issue4473@psf.upfronthosting.co.za> Lorenzo M. Catucci added the comment: I'm reasonably sure Victor is right about the original socket being unneeded. How does the series look now? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:44:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2008 12:44:19 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228221859.46.0.709908551559.issue4473@psf.upfronthosting.co.za> STINNER Victor added the comment: "lst[1:] if len(lst)>1 else []" is useless, lst[1:] alone does the same :-) So it can be simplify to: def _parsecap(line): lst = line.split() return lst[0], lst[1:] You might add a real example in the capa() docstring. About poplib_02_sock_shutdown.diff: I'm not sure that poplib is the right place to fix the issue... if there is really an issue. Why not calling shutdown directly in socket.close()? :-) You removed self._sock, nice. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:00:15 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 13:00:15 +0000 Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> Message-ID: <1228222815.22.0.392017514066.issue2464@psf.upfronthosting.co.za> John J Lee added the comment: This fix was applied in the wrong place. URI path components, and HTTP URI path components in particular, *can* be empty. See RFC 3986. So the comment in the code that was inserted with the fix for this bug that says "possibly malformed" is incorrect, and should instead just refer to section 3.2.2 of RFC 2616. Also, because 3.2.2 says "If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2)", it seems clear that this transformation (add the slash if there's no path component) should always happen when retrieving URIs, regardless of where the URI came from -- not only for redirects. Note that RFC 2616 incorrectly claims to refer to the definition of abs_path from RFC 2396. The fact that it's incorrect is made clear in 2616 itself, in section 3.2.3, when it says that abs_path can be empty. In any case, RFC 2396 is obsoleted by RFC 3986, which is clear on this issue, and reflects actual usage of URIs. URIs like http://python.org and http://python.org?spam=eggs have been in widespread use for a long time, and typing the latter URL into firefox (3.0.2) confirms that what's actually sent is "/?spam", whereas urllib2 still sends "?spam". No test was added with this fix, which makes it unnecessarily hard to work out what exactly the fix was supposed to fix. For the record, this is the sequence of redirections before the fix was applied (showing base URI + redirect URI reference --> redirect URI): 'http://www.wikispaces.com' + 'https://session.wikispaces.com/session/auth?authToken=token' --> 'https://session.wikispaces.com/session/auth?authToken=token' 'https://session.wikispaces.com/session/auth?authToken=token' + 'http://www.wikispaces.com?responseToken=token' --> 'http://www.wikispaces.com?responseToken=token' and after the fix was applied: 'http://www.wikispaces.com' + 'https://session.wikispaces.com/session/auth?authToken=token' --> 'https://session.wikispaces.com/session/auth?authToken=token' 'https://session.wikispaces.com/session/auth?authToken=token' + 'http://www.wikispaces.com/?responseToken=token' --> 'http://www.wikispaces.com/?responseToken=token' 'http://www.wikispaces.com/?responseToken=token' + 'http://www.wikispaces.com/' --> 'http://www.wikispaces.com/' ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:10:55 2008 From: report at bugs.python.org (maxua) Date: Tue, 02 Dec 2008 13:10:55 +0000 Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py Message-ID: <1228223455.3.0.699444534089.issue1368247@psf.upfronthosting.co.za> maxua added the comment: How about this version? ---------- nosy: +maxua Added file: http://bugs.python.org/file12190/mimetext-unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:17:12 2008 From: report at bugs.python.org (maxua) Date: Tue, 02 Dec 2008 13:17:12 +0000 Subject: [issue4487] Add utf8 alias for email charsets In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za> Message-ID: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za> New submission from maxua : When using MIME email package you can specify "utf8" as the encoding. It will be accepted but it is not rendered correctly in some MUA. E.g. Mac OS X Mail.app doesn't display it properly while Google Gmail does. It is confusing since Python itself happily understands both utf8 and utf-8. The patch adds "utf8" as an alias to "utf-8" encoding which means user won't need to think twice. Test case: from email.MIMEText import MIMEText msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430') msg.set_charset('utf8') print msg.as_string() ---------- components: Library (Lib) files: charset-utf8-alias.patch keywords: patch messages: 76738 nosy: maxua severity: normal status: open title: Add utf8 alias for email charsets versions: Python 2.5 Added file: http://bugs.python.org/file12191/charset-utf8-alias.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:46:00 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 13:46:00 +0000 Subject: [issue3819] urllib2 sends Basic auth across redirects In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za> Message-ID: <1228225560.1.0.617644119164.issue3819@psf.upfronthosting.co.za> John J Lee added the comment: I agree this is a bug. Senthil -- re "1)", the paragraph you refer to (quoted by the OP) is relevant. The fact that it doesn't specifically mention redirection is not relevant. Re "2)": I don't know how digest auth works, but the paragraph you quote from appears to be there for explanation rather than for prescribing how digest auth or HTTP work (i.e. it appears to be "non-normative"). This bug doesn't say that redirected requests shouldn't contain the Authorization header. It says that the Authorization header for an old request shouldn't be sent with a new request (though it may turn out the new one is equal to the old one in some cases). ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:52:17 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2008 13:52:17 +0000 Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py Message-ID: <1228225937.24.0.239362403026.issue1368247@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:53:20 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2008 13:53:20 +0000 Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py Message-ID: <1228226000.32.0.356468871857.issue1368247@psf.upfronthosting.co.za> STINNER Victor added the comment: It was proposed to rewrite MIMEText in Python 3.1 (and 2.7?) to use unicode characters in the internals and reconvert to bytes to send it to a socket (or a file). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:54:22 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2008 13:54:22 +0000 Subject: [issue4487] Add utf8 alias for email charsets In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za> Message-ID: <1228226062.32.0.7176618925.issue4487@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:56:59 2008 From: report at bugs.python.org (Damjan Georgievski) Date: Tue, 02 Dec 2008 13:56:59 +0000 Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py Message-ID: <1228226219.18.0.10794975557.issue1368247@psf.upfronthosting.co.za> Damjan Georgievski added the comment: The patch by maxua works fine with 2.6 too and solves the problem. I'd suggest it be applied to the 2.6 branch, even if email is rewriten for 2.7/3.x. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:12:10 2008 From: report at bugs.python.org (Jesse Noller) Date: Tue, 02 Dec 2008 14:12:10 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228227130.66.0.42211005511.issue4449@psf.upfronthosting.co.za> Jesse Noller added the comment: This is not a doc bug - in actuality, the mp_benchmarks.py example is exposing an assertion error in sharedctypes.py. The doc-related bugs Christian and I spoke about have been fixed, however the main issue for this (the assertion error) is still in the code, and I haven't had a chance to trace it down and fix it. ---------- components: +Extension Modules -Documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:13:44 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 14:13:44 +0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python In-Reply-To: <1190793332.9.0.29899287923.issue1205@psf.upfronthosting.co.za> Message-ID: <1228227224.71.0.753333335533.issue1205@psf.upfronthosting.co.za> John J Lee added the comment: This is fixed in trunk r61034 by issue #900744 . Please use that issue for any discussion re whether this should be fixed in 2.5. ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:26:33 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 14:26:33 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228227993.64.0.220663281066.issue4473@psf.upfronthosting.co.za> Lorenzo M. Catucci added the comment: Changed CAPA as requested: now there is a proper docstring, and the useless if ... else ... is gone. Added file: http://bugs.python.org/file12192/poplib_01_CAPA.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:26:45 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 14:26:45 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228228005.65.0.269213549088.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Removed file: http://bugs.python.org/file12186/poplib_01_CAPA.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:31:04 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 14:31:04 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1228228264.02.0.128612224516.issue4473@psf.upfronthosting.co.za> Lorenzo M. Catucci added the comment: As for the shutdown/close comment, I think there could be cases where you are going to close but don't want to shutdown: e.g. you might close a dup-ed socket, but the other owner would want to continue working with his copy of the socket. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:33:59 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2008 14:33:59 +0000 Subject: [issue4486] Exception traceback is incorrect for strange exception handling In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> Message-ID: <1228228439.08.0.282233941417.issue4486@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The current behaviour is the result of how I interpreted the error reporting specification in PEP 3134. See "Enhanced Reporting" in http://www.python.org/dev/peps/pep-3134/ . I may have misinterpreted it, in that both the cause and the context are printed out while the PEP may be read as suggesting the context must not be printed out when there is a cause. In any case, I don't think it is a release blocker. It only regards a new and advanced feature (explicit exception chaining) and doesn't disrupt its functioning. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:38:27 2008 From: report at bugs.python.org (Martin Meredith) Date: Tue, 02 Dec 2008 14:38:27 +0000 Subject: [issue4488] Python Documentation not Newb Friendly In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> Message-ID: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> New submission from Martin Meredith : I'm a new python user (developing in python) and I recently had a discussion with someone that my main issue with python is finding where the functions are that I need to use. An example (probably not the best) - I need to split a filename so that I can have the extension and the rest of the filename seperate. Fine.. I google, and I get the following page:- http://www.python.org/doc/2.5.2/lib/os-path.html Now, that lists the function splitext - which is what I need - but it's not clear on the page where that function is located (os.path) I think that this should be made clearer somehow - as it seems to me that you have to go through about 3 pages trying to work out where it is (or work it out from the URL) - which isn't very intuitive, espescially for a new user, who doesn't actually know where all the functions exist. ---------- assignee: georg.brandl components: Documentation messages: 76747 nosy: georg.brandl, mez severity: normal status: open title: Python Documentation not Newb Friendly type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:43:12 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 14:43:12 +0000 Subject: [issue1537445] urllib2 httplib _read_chunked timeout Message-ID: <1228228992.42.0.451620331507.issue1537445@psf.upfronthosting.co.za> John J Lee added the comment: urlopen() raises URLError, .read() may raise other errors. I don't think that's a bug in itself, though no doubt: 1. The documentation of exceptions raised could and should be improved 2. The exceptions that can be raised are likely still inconsistent (though this has improved in Python 2.6, I think) Recommend closing this bug. Please open other bugs about the issues above if you have patches. ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:50:46 2008 From: report at bugs.python.org (Tim Golden) Date: Tue, 02 Dec 2008 14:50:46 +0000 Subject: [issue4488] Python Documentation not Newb Friendly In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> Message-ID: <49354BE5.4040000@timgolden.me.uk> Tim Golden added the comment: What would be helpful would be a specific suggestion from the OP (or, better still, a doc patch) as to exactly what should change or at least what kind of words should go where. As it stands, this report highlights a real but quite general issue issue but doesn't take us anywhere towards how we could improve things. ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:59:30 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 14:59:30 +0000 Subject: [issue1123695] attempting to use urllib2 on some URLs fails starting on 2.4 Message-ID: <1228229970.05.0.299798763233.issue1123695@psf.upfronthosting.co.za> John J Lee added the comment: Can somebody close this? It's fixed on trunk in #900744 . _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:31:35 2008 From: report at bugs.python.org (Martin Meredith) Date: Tue, 02 Dec 2008 15:31:35 +0000 Subject: [issue4488] Python Documentation not Newb Friendly In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> Message-ID: <1228231895.14.0.424941929733.issue4488@psf.upfronthosting.co.za> Martin Meredith added the comment: Well, I can't offer a patch (as I said - I'm a python n00b) - but I can offer suggestions. 1) show the functions as where they are - for example - splitext would be shown as os.path.splitext(arguments) 2) header titles for groups within the same module. So splitext, etc etc, would be under a visible title that says "os.path" 3) alternate documentation links by modules. So the documentation stays the same, but there is also an alternate set which shows the same things, but where the "up" button would take me from os.path to os (showing that that is the module title) rather than the title being 14.1.6 Miscellaneous System Information In fact - 3 exists - sort of, it just seems a little wrong. Link 1: http://www.python.org/doc/2.5.2/lib/os-path.html Title: 14.1.6 Miscellaneous System Information How to get there:- Python Library Reference -> Generic Operating System Services -> os -> Miscellaneous System Information Link 2: http://www.python.org/doc/2.5.2/lib/module-os.path.html Title: 11.1 os.path -- Common pathname manipulations How to Get there:- Python Library Reference -> File and Directory Access -> os.path -- Common pathname manipulations Link 2 seems to give the information in a good way - but didn't show on my "quickly search google" radar. Plus, the way to get there seems wrong. It should (IMO) be accessible through "Python Library Reference -> modules -> os -> os.path" or something similar. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:41:49 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 15:41:49 +0000 Subject: [issue4471] IMAP4 missing support for starttls In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za> Message-ID: <1228232509.09.0.891613080174.issue4471@psf.upfronthosting.co.za> Lorenzo M. Catucci added the comment: As requested, I've split the patch into three parts: the first one does just refactor IMAP4_SSL, the second is really a one liner for shutting down the socket before closing it, and the thirs does introduce the starttls method in IMAP4. Added file: http://bugs.python.org/file12193/imaplib_01_SSL_refactor.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:42:02 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Tue, 02 Dec 2008 15:42:02 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> New submission from Mart S?mermaa : Race condition in the rmtree function in the shutils module allows local users to delete arbitrary files and directories via a symlink attack. See also http://bugs.debian.org/286922 Attack: --- # emulate removing /etc $ sudo cp -a /etc /root/etc/ $ sudo python2.6 >>> for i in xrange(0, 50000): ... with open("/root/etc/" + str(i), "w") as f: ... f.write("0") ... $ ls /root/etc > orig_list.txt $ mkdir /tmp/attack $ cp -a /root/etc/* /tmp/attack $ sudo python2.6 >>> from shutil import rmtree >>> rmtree('/tmp/attack') >>> # press ctrl-z to suspend execution ^Z [1]+ Stopped sudo python2.6 $ mv /tmp/attack /tmp/dummy; ln -s /root/etc /tmp/attack $ fg sudo python2.6 Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.6/shutil.py", line 225, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "/usr/local/lib/python2.6/shutil.py", line 223, in rmtree os.rmdir(path) OSError: [Errno 20] Not a directory: '/tmp/attack' $ ls /root/etc > new_list.txt $ diff -q orig_list.txt new_list.txt Files orig_list.txt and new_list.txt differ --- If the attack wasn't successful, /root/etc would not be modified and orig_list.txt and new_list.txt would be identical. ---------- components: Library (Lib) messages: 76753 nosy: mrts severity: normal status: open title: shutil.rmtree is vulnerable to a symlink attack type: security versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:42:26 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 15:42:26 +0000 Subject: [issue4471] IMAP4 missing support for starttls In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za> Message-ID: <1228232546.8.0.955121795771.issue4471@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12194/imaplib_02_shutdown.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:42:41 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 15:42:41 +0000 Subject: [issue4471] IMAP4 missing support for starttls In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za> Message-ID: <1228232561.7.0.441172801918.issue4471@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12195/imaplib_03_starttls.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:42:49 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 15:42:49 +0000 Subject: [issue4471] IMAP4 missing support for starttls In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za> Message-ID: <1228232569.09.0.717024203658.issue4471@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Removed file: http://bugs.python.org/file12169/imaplib.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:52:56 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Tue, 02 Dec 2008 15:52:56 +0000 Subject: [issue4490] xml/sax/expatreader.py raises AttributeError when run In-Reply-To: <1228233176.69.0.228694076169.issue4490@psf.upfronthosting.co.za> Message-ID: <1228233176.69.0.228694076169.issue4490@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone : expatreader.py has a __main__ which uses something called `xml.sax.XMLGenerator?. However, `xml.sax? has no such attribute. ---------- components: Library (Lib) messages: 76754 nosy: exarkun severity: normal status: open title: xml/sax/expatreader.py raises AttributeError when run versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:10:49 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 16:10:49 +0000 Subject: [issue1123695] attempting to use urllib2 on some URLs fails starting on 2.4 Message-ID: <1228234249.39.0.736753769486.issue1123695@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- resolution: -> out of date status: open -> closed superseder: -> catch invalid chunk length in httplib read routine _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:15:59 2008 From: report at bugs.python.org (Atsuo Ishimoto) Date: Tue, 02 Dec 2008 16:15:59 +0000 Subject: [issue4491] email.Header.decode_header() doesn't work if encoded-word was separeted by CRLF In-Reply-To: <1228234559.58.0.381415224429.issue4491@psf.upfronthosting.co.za> Message-ID: <1228234559.58.0.381415224429.issue4491@psf.upfronthosting.co.za> New submission from Atsuo Ishimoto : email.Header.decode_header() doesn't work if encoded-word was separeted by CRLF. For exmaple, decode_header('=?iso-8859-1?q?hello?=\r\n world.') returns [('=?iso-8859-1?q?hello?=\r\n world.', None)], not [('hello', 'iso-8859-1'), (' world.', None)]. This bug was caused by rev.54371, bug #1582282. I attached a patch to fix problem and test-case. ---------- components: Library (Lib) files: email.patch keywords: patch messages: 76755 nosy: ishimoto severity: normal status: open title: email.Header.decode_header() doesn't work if encoded-word was separeted by CRLF type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file12196/email.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:27:06 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 16:27:06 +0000 Subject: [issue4488] Python Documentation not Newb Friendly In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> Message-ID: <1228235226.87.0.712236029543.issue4488@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Did you see that the current (=2.6) documentation has changed a lot? For example: http://docs.python.org/library/os.path.html#os.path.splitext It seems that most of your concerns have been addressed. (also, see the nice URL) I suggest that you try it, and address your recommendations from there. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:29:23 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 02 Dec 2008 16:29:23 +0000 Subject: [issue4488] Python Documentation not Newb Friendly In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> Message-ID: <1228235363.93.0.724603695688.issue4488@psf.upfronthosting.co.za> Georg Brandl added the comment: Like Amaury said, I think this is fixed. ---------- resolution: -> fixed status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:31:25 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2008 16:31:25 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za> Message-ID: <1228235485.76.0.856387065147.issue2306@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The "optimizations" section needn't be so pessimistic. I just compiled the latest py3k and release2.5-maint branches and py3k is 10% slower (38000 vs. 42000). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:32:40 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 16:32:40 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1228235560.12.0.263894283938.issue4470@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Removed file: http://bugs.python.org/file12168/smtplib.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:32:54 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 16:32:54 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1228235574.49.0.0269417974258.issue4470@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12197/smtplib_01_default_port.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:33:04 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 16:33:04 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1228235584.47.0.70825311146.issue4470@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12198/smtplib_02_fix_ssl.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:33:13 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 16:33:13 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1228235593.96.0.685836312428.issue4470@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12199/smtplib_03_use_makefile.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:33:22 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 16:33:22 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1228235602.76.0.014322650647.issue4470@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci : Added file: http://bugs.python.org/file12200/smtplib_04_remove_fakefile.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:34:33 2008 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Tue, 02 Dec 2008 16:34:33 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1228235673.95.0.691739081295.issue4470@psf.upfronthosting.co.za> Lorenzo M. Catucci added the comment: I've reworked the patch into a series, like haypo requested for poplib and imaplib. Added file: http://bugs.python.org/file12201/smtplib_05_shutdown_socket.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:32:30 2008 From: report at bugs.python.org (Leger) Date: Tue, 02 Dec 2008 17:32:30 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228239150.15.0.507031526019.issue4483@psf.upfronthosting.co.za> Leger added the comment: - I modify your dbm2.diff because the module name is "_dbmmodule.c" and not "dbmmodule.c". - Patching success - new test "configure ... ; make" and make stop with error : "... gcc -pthread -shared build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/_ctypes.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/callbacks.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/callproc.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/stgdict.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/cfield.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/malloc_closure.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/libffi/src/prep_cif.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -L. -lpython3.0 -o build/lib.linux-i686-3.0-pydebug/_ctypes.so Failed to build these modules: _dbm running build_scripts creating build/scripts-3.0 copying and adjusting /install/python-3.0rc3.diff/Tools/scripts/pydoc -> build/scripts-3.0 copying and adjusting /install/python-3.0rc3.diff/Tools/scripts/idle -> build/scripts-3.0 copying and adjusting /install/python-3.0rc3.diff/Tools/scripts/2to3 -> build/scripts-3.0 copying and adjusting /install/python-3.0rc3.diff/Lib/smtpd.py -> build/scripts-3.0 changing mode of build/scripts-3.0/pydoc from 644 to 755 changing mode of build/scripts-3.0/idle from 644 to 755 changing mode of build/scripts-3.0/2to3 from 644 to 755 changing mode of build/scripts-3.0/smtpd.py from 644 to 755 [88798 refs]" Added file: http://bugs.python.org/file12202/dbm2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:51:57 2008 From: report at bugs.python.org (Leger) Date: Tue, 02 Dec 2008 17:51:57 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228240317.19.0.190177035846.issue4483@psf.upfronthosting.co.za> Leger added the comment: I retest with light configure modification and dbm2.diff with file name "_dbmmodule.c" : "configure --with-pydebug --with-doc-strings --enable-shared --enable-profiling --enable-ipv6 --with-threads --with-tsc --prefix=/usr ; make" "... gcc -pthread -shared build/temp.linux-i686-3.0-pydebug/install/python-3.0rc3.diff/Modules/_dbmmodule.o -L/usr/local/lib -L. -lgdbm -lpython3.0 -o build/lib.linux-i686-3.0-pydebug/_dbm.so *** WARNING: renaming "_dbm" since importing it failed: build/lib.linux-i686-3.0-pydebug/_dbm.so: undefined symbol: dbm_firstkey Failed to build these modules: _dbm running build_scripts [89618 refs]" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:01:52 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 02 Dec 2008 18:01:52 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1228240912.39.0.917689426303.issue4347@psf.upfronthosting.co.za> Brett Cannon added the comment: Because of all the patch includes a bunch of junk for generated files (any chance you can make a diff, Thomas, with only the stuff that really requires review?), I have not done a real review. But a quick look does show that the comment added to Grammar needs to be tweaked. Please use complete sentences, including punctuation (e.g., capitalize words, end in a period, etc.). Also don't use XXX just to grab attention for something that is not meant to be removed. ---------- nosy: +brett.cannon stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:02:37 2008 From: report at bugs.python.org (Kevin Watters) Date: Tue, 02 Dec 2008 18:02:37 +0000 Subject: [issue3001] RLock's are SLOW In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za> Message-ID: <1228240957.9.0.910523917271.issue3001@psf.upfronthosting.co.za> Changes by Kevin Watters : ---------- nosy: +kevinwatters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:12:38 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 02 Dec 2008 18:12:38 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228239150.15.0.507031526019.issue4483@psf.upfronthosting.co.za> Message-ID: <18741.31378.95950.920866@montanaro-dyndns-org.local> Skip Montanaro added the comment: Leger> - I modify your dbm2.diff because the module name is Leger> "_dbmmodule.c" and not "dbmmodule.c". I think you missed the point of the dbm2.diff file. It should be applied to the Python 2.x code, not to Python 3.x. I don't have access to the necessary platform to run the test. To summarize: * dbm.diff should be applied to the py3k branch (or to the 3.0rc3 release code). * dbm2.diff should be applied to the code on the trunk (or to the 2.6 release code). Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:15:19 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 18:15:19 +0000 Subject: [issue4492] httplib code thinks it closes connection, but does not In-Reply-To: <1228241719.92.0.946688230988.issue4492@psf.upfronthosting.co.za> Message-ID: <1228241719.92.0.946688230988.issue4492@psf.upfronthosting.co.za> New submission from John J Lee : The fix for #900744 tried to close the connection when a bad chunk length was received. The comment inserted with that fix "close the connection as protocol synchronisation is probably lost" is incorrect: self.close() in _read_chunked does not close the connection. You have to call HTTPConnection.close() to close the connection. So: * The comment is incorrect, and should be removed or fixed. I guess the self.close() should stay. * It's probably a bug that it doesn't result in the connection being closed. I guess a fix for that would be for the HTTPResponse to set some state on itself that HTTPConnection can query so that HTTPConnection can close itself the next time somebody tries to do something with the connection. ---------- components: Library (Lib) messages: 76764 nosy: jjlee severity: normal status: open title: httplib code thinks it closes connection, but does not type: behavior versions: Python 2.6, Python 2.7, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:18:00 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 18:18:00 +0000 Subject: [issue900744] catch invalid chunk length in httplib read routine Message-ID: <1228241880.6.0.461703613147.issue900744@psf.upfronthosting.co.za> John J Lee added the comment: The fix for this doesn't actually close the connection as the comment in the fix claims -- I've raised #4492 to track that. ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 20:13:15 2008 From: report at bugs.python.org (Leger) Date: Tue, 02 Dec 2008 19:13:15 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228245195.49.0.6661115743.issue4483@psf.upfronthosting.co.za> Leger added the comment: Skip, Sorry for my mistake with dbm2.diff ;) >From the tar 3.0rc3 I apply the patch (dbm.diff). Configure ... and make. But the result is always wrong : "Failed to build these modules: _dbm" Best regards, Frederic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 20:27:35 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 19:27:35 +0000 Subject: [issue1411097] httplib patch to make _read_chunked() more robust Message-ID: <1228246055.69.0.356486838929.issue1411097@psf.upfronthosting.co.za> John J Lee added the comment: For the record, I think my worry in msg49366 was a non-issue: the only time .readline() will return "" is when the connection has closed (so I think the fix that eventually applied is correct). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 20:50:24 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 19:50:24 +0000 Subject: [issue1772481] urllib2 hangs with some documents. Message-ID: <1228247424.38.0.275264550797.issue1772481@psf.upfronthosting.co.za> John J Lee added the comment: Please close: this is already fixed on trunk and release25-maint (r60747, issue #1966) (and on release26-maint, which was branched after the fix). ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 20:51:29 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 02 Dec 2008 19:51:29 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228245195.49.0.6661115743.issue4483@psf.upfronthosting.co.za> Message-ID: <18741.37308.511364.69580@montanaro-dyndns-org.local> Skip Montanaro added the comment: Frederic> From the tar 3.0rc3 I apply the patch (dbm.diff). Configure Frederic> ... and make. But the result is always wrong : > "Failed to build these modules: > _dbm" Why does it fail? Is there compile error? Does linking fail? I guessed that the library would still be "gdbm", but I don't really know. Does your system maybe install a library file named "libgdbm-ndbm.so" or something similarly obscure? I'm happy to try and get this resolved, but not that there is only another day or two before 3.0final is released. (This might not make the release anyway.) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:06:33 2008 From: report at bugs.python.org (Leger) Date: Tue, 02 Dec 2008 20:06:33 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228248393.07.0.146915182415.issue4483@psf.upfronthosting.co.za> Leger added the comment: - Only the make generate last error sentence. - Debian/Lenny provide only "libgdbm-dev-1.8.3-3" provide : root at xxx:/install# ll /usr/lib/libgdbm.so* lrwxrwxrwx 1 root root 16 2008-12-01 21:45 /usr/lib/libgdbm.so -> libgdbm.so.3.0.0 lrwxrwxrwx 1 root root 16 2008-03-08 21:38 /usr/lib/libgdbm.so.3 -> libgdbm.so.3.0.0 -rw-r--r-- 1 root root 19940 2006-04-24 05:25 /usr/lib/libgdbm.so.3.0.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:07:06 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Dec 2008 20:07:06 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za> Message-ID: <1228248426.38.0.442103542843.issue2306@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Guido, ETA? I think this will be one of the last things before we can tag the tree for release. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:12:03 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 20:12:03 +0000 Subject: [issue1772481] urllib2 hangs with some documents. Message-ID: <1228248723.95.0.349383724164.issue1772481@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Thanks for the review! ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed superseder: -> infinite loop in httplib _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:16:48 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Dec 2008 20:16:48 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228249008.21.0.838614166475.issue4449@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Jesse, does this affect Python 3.0? If not, then I will lower the priority and release 2.6.1 without it (there's always 2.6.2 :). If so, then we need to know if 1) it's really a release blocker; 2) what the ETA on a fix is. I would like to tag the 3.0 branch today. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:18:28 2008 From: report at bugs.python.org (Jesse Noller) Date: Tue, 02 Dec 2008 20:18:28 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228249108.78.0.201358372696.issue4449@psf.upfronthosting.co.za> Jesse Noller added the comment: 2.6.0 shipped with the assertion error. Unfortunately, I'm tapped out at the day job right now, so I won't have a fix prepped and tested in time. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:22:40 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Dec 2008 20:22:40 +0000 Subject: [issue4486] Exception traceback is incorrect for strange exception handling In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> Message-ID: <1228249360.92.0.93517124965.issue4486@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: This looks like it only affects printing exceptions with implicit chaining when the exception propagates to the top level. (Maybe it also affects the traceback module?) In that case, I agree with Antoine. Let's fix it in 3.0.1. ---------- priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:26:33 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 20:26:33 +0000 Subject: [issue4079] new urllib2.Request 'timeout' attribute needs to have a default In-Reply-To: <1223490599.12.0.198174561396.issue4079@psf.upfronthosting.co.za> Message-ID: <1228249593.29.0.177488917494.issue4079@psf.upfronthosting.co.za> John J Lee added the comment: This bug was known before the release -- unfortunately the original author of the patch didn't fix them in time. This and some other unresolved issues listed are listed on #2451. "Somebody" should raise bugs about the rest of them too, and fix them. (Senthil, is that the bug you meant to refer to? You pasted this bug's own URL here, presumably you meant to paste the URL for a different bug?) ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:29:11 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 20:29:11 +0000 Subject: [issue4079] new urllib2.Request 'timeout' attribute needs to have a default In-Reply-To: <1223490599.12.0.198174561396.issue4079@psf.upfronthosting.co.za> Message-ID: <1228249751.88.0.630086822865.issue4079@psf.upfronthosting.co.za> Changes by John J Lee : ---------- nosy: +facundobatista _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:46:12 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 20:46:12 +0000 Subject: [issue4493] urllib2 doesn't always supply / where URI path component is empty In-Reply-To: <1228250772.41.0.047917224679.issue4493@psf.upfronthosting.co.za> Message-ID: <1228250772.41.0.047917224679.issue4493@psf.upfronthosting.co.za> New submission from John J Lee : As required by RFC 2616 section 3.2.2, for all HTTP requests sent by urllib2, the path component of the URI should be normalized to "/" before the Request-URI derived from it gets passed to httplib (or something functionally equivalent to that). This was fixed in one case in #2464, but the fix is in the wrong place, since it's a general problem not specific to redirects. See the longer discussion here: http://bugs.python.org/msg76736 (hmm, let's see if I can just say msg76736 and get a hyperlink) Example: import urllib2 urllib2.urlopen("http://python.org?spam") Expect: sends "/?spam" in request line. Got: sends "?spam" in request line. Probably should be fixed by making Request.get_selector() return the normalized URI reference (with the slash always present). When fixing, remember that the Request-URI of RFC 2616 (returned by .get_selector()) is sometimes a relative reference, and sometimes a URI (in RFC 3986's terminology). ---------- messages: 76777 nosy: jjlee severity: normal status: open title: urllib2 doesn't always supply / where URI path component is empty _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:47:14 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 20:47:14 +0000 Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> Message-ID: <1228250834.78.0.0219269716415.issue2464@psf.upfronthosting.co.za> John J Lee added the comment: I've raised #4493 about the issue I raised in my previous comment. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:47:38 2008 From: report at bugs.python.org (Alexey Borzenkov) Date: Tue, 02 Dec 2008 20:47:38 +0000 Subject: [issue4494] Python 2.6 fails to build with Py_NO_ENABLE_SHARED In-Reply-To: <1228250858.27.0.203382984925.issue4494@psf.upfronthosting.co.za> Message-ID: <1228250858.27.0.203382984925.issue4494@psf.upfronthosting.co.za> New submission from Alexey Borzenkov : When building python 2.6 with Py_NO_ENABLE_SHARED compilation fails on PC/getpathp.c, because it uses PyWin_DLLVersionString and PyWin_DLLhModule unconditionally, which are implemented in PC/dl_nt.c only when Py_ENABLE_SHARED is defined. The attached patch fixes the problem by wrapping dependent parts in if #ifdef Py_ENABLE_SHARED/#endif. ---------- components: Windows files: python-2.6-static.patch keywords: patch messages: 76778 nosy: snaury severity: normal status: open title: Python 2.6 fails to build with Py_NO_ENABLE_SHARED type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file12203/python-2.6-static.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:49:55 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Dec 2008 20:49:55 +0000 Subject: [issue4486] Exception traceback is incorrect for strange exception handling In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> Message-ID: <1228250995.19.0.0372480075812.issue4486@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that the display is correct in the case where the chaining is "right", i.e.: try: raise IOError except: try: raise KeyError except Exception as ex: raise AttributeError from ex In that case, IOError is correctly flagged as the original exception, with a KeyError then occurring during the IOError handling, and the KeyError then directly causing the AttributeError. The weird thing I am doing in the example here is to set the __cause__ of the exception I am raising to an exception that was never itself actually raised (the "from KeyError" bit). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:53:03 2008 From: report at bugs.python.org (Alexey Borzenkov) Date: Tue, 02 Dec 2008 20:53:03 +0000 Subject: [issue4494] Python 2.6 fails to build with Py_NO_ENABLE_SHARED In-Reply-To: <1228250858.27.0.203382984925.issue4494@psf.upfronthosting.co.za> Message-ID: <1228251183.98.0.485216184114.issue4494@psf.upfronthosting.co.za> Changes by Alexey Borzenkov : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:53:09 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 02 Dec 2008 20:53:09 +0000 Subject: [issue4495] Fix signed/unsigned warning In-Reply-To: <1228251189.49.0.297492395281.issue4495@psf.upfronthosting.co.za> Message-ID: <1228251189.49.0.297492395281.issue4495@psf.upfronthosting.co.za> New submission from Raymond Hettinger : C:\py30>svn diff Index: Python/traceback.c =================================================================== --- Python/traceback.c (revision 67476) +++ Python/traceback.c (working copy) @@ -171,7 +171,7 @@ if (!PyUnicode_Check(v)) continue; path = _PyUnicode_AsStringAndSize(v, &len); - if (len + 1 + taillen >= (Py_ssize_t)namelen - 1) + if (len + 1 + (Py_ssize_t)taillen >= (Py_ssize_t)namelen - 1) continue; /* Too long */ strcpy(namebuf, path); if (strlen(namebuf) != len) ---------- assignee: barry components: Interpreter Core messages: 76781 nosy: barry, rhettinger severity: normal status: open title: Fix signed/unsigned warning type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:58:10 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 02 Dec 2008 20:58:10 +0000 Subject: [issue4494] Python 2.6 fails to build with Py_NO_ENABLE_SHARED In-Reply-To: <1228250858.27.0.203382984925.issue4494@psf.upfronthosting.co.za> Message-ID: <1228251490.03.0.76744824057.issue4494@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- assignee: -> loewis priority: -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:00:34 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 02 Dec 2008 21:00:34 +0000 Subject: [issue4495] Fix signed/unsigned warning In-Reply-To: <1228251189.49.0.297492395281.issue4495@psf.upfronthosting.co.za> Message-ID: <1228251634.73.0.535217729656.issue4495@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed r67477. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:07:39 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 21:07:39 +0000 Subject: [issue4496] misleading comment in urllib2 In-Reply-To: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za> Message-ID: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za> New submission from John J Lee : r54137 replaced a comment in urllib2.py with a misleading comment. The comment now implies the .insort() in question achieves the goal specified in the new comment. That's not true, which was the reason the original comment was there in the first place. At least replace the comment with the original comment. Alternatively, (correctly) resolve the question in the original comment somehow (for example by removing the .handlers attribute -- but since .handlers is misnamed in not having an initial underscore, it may have tempted people to use it, even though it's undocumented, hence private). ---------- messages: 76783 nosy: jjlee severity: normal status: open title: misleading comment in urllib2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:10:23 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 21:10:23 +0000 Subject: [issue4496] misleading comment in urllib2 In-Reply-To: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za> Message-ID: <1228252223.29.0.28170811338.issue4496@psf.upfronthosting.co.za> Changes by John J Lee : ---------- components: +Library (Lib) nosy: +facundobatista versions: +Python 2.7, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:10:34 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 21:10:34 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228252234.16.0.478280184221.issue4449@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is a patch nonetheless. It makes the code match the the documentation: http://docs.python.org/library/multiprocessing.html#multiprocessing.sharedctypes.Arra y """ - If lock is True (the default) then a new lock object is created to synchronize access to the value. - If lock is a Lock or RLock object then that will be used to synchronize access to the value. - If lock is False then access to the returned object will not be automatically protected by a lock, so it will not necessarily be process-safe. """ I changed multiprocessing.sharedctypes.Array and multiprocessing. sharedctypes.Array I had to change some tests: now "lock=None" is an error. + some markup fixes in the documentation. ---------- keywords: +patch nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file12204/mp_array.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:15:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 02 Dec 2008 21:15:12 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228252512.32.0.420248429239.issue4449@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch looks fine. However I propose to replace the assert statement with a proper check that raises a meaningful exception. if not hasattr(lock, 'acquire'): raise AttributeError("'%r' has no method 'acquire'" % lock) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:17:51 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Dec 2008 21:17:51 +0000 Subject: [issue4486] Exception traceback is incorrect for strange exception handling In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> Message-ID: <1228252671.54.0.213749577063.issue4486@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looks to me like the display code is getting confused by the lack of a non-None __context__ on the KeyError. Perhaps the "raise ex from cause" syntax should be setting the __context__ on the "cause" exception if it isn't already set? Or else we could just special case this kind of weird programmer behaviour in the display code. ======================= >>> try: ... raise IOError ... except Exception as ex: ... ke = KeyError() ... ke.__context__ = ex ... raise AttributeError from ke ... Traceback (most recent call last): File "", line 2, in IOError During handling of the above exception, another exception occurred: KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 6, in AttributeError ======================= _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:35:18 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 02 Dec 2008 21:35:18 +0000 Subject: [issue3689] listreverseiterator has a decreasing len() In-Reply-To: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za> Message-ID: <1228253718.71.0.0953996969801.issue3689@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed r67478. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:37:44 2008 From: report at bugs.python.org (Jesse Noller) Date: Tue, 02 Dec 2008 21:37:44 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228253864.67.0.853331503118.issue4449@psf.upfronthosting.co.za> Jesse Noller added the comment: +1 on Amaury's patch, however I wouldn't change the assert right now - Christian's suggestion does make sense to change globally post 3.0 Amaury, do you want to submit it? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:40:57 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 02 Dec 2008 21:40:57 +0000 Subject: [issue4497] Compiler warnings in longobject.c In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> Message-ID: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> New submission from Raymond Hettinger : longobject.c ..\..\Objects\longobject.c(201) : warning C4244: '=' : conversion from 'long' to 'digit', possible loss of data ..\..\Objects\longobject.c(212) : warning C4244: '=' : conversion from 'long' to 'digit', possible loss of data ..\..\Objects\longobject.c(1063) : warning C4244: 'function' : conversion from '__int64' to 'int', possible loss of data ..\..\Objects\longobject.c(1106) : warning C4244: 'function' : conversion from 'unsigned __int64' to 'long', possible loss of data ---------- assignee: marketdickinson components: Interpreter Core messages: 76789 nosy: marketdickinson, rhettinger priority: normal severity: normal status: open title: Compiler warnings in longobject.c versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:42:11 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Dec 2008 21:42:11 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228254131.05.0.328341579787.issue4449@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I don't much like the lock is True lock is False idioms much, but I don' thave a better suggestion, and it would be nice to fix this for the releases. ---------- resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:48:33 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 02 Dec 2008 21:48:33 +0000 Subject: [issue4498] Compiler warning "signed/unsigned comparion in mmapmodule" In-Reply-To: <1228254513.06.0.0352568369142.issue4498@psf.upfronthosting.co.za> Message-ID: <1228254513.06.0.0352568369142.issue4498@psf.upfronthosting.co.za> New submission from Raymond Hettinger : mmapmodule.c: lines 247-248 /* silently 'adjust' out-of-range requests */ if (num_bytes > self->size - self->pos) { ---------- assignee: nnorwitz components: Interpreter Core messages: 76791 nosy: nnorwitz, rhettinger priority: normal severity: normal status: open title: Compiler warning "signed/unsigned comparion in mmapmodule" type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:48:51 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 21:48:51 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228254531.69.0.173146632789.issue4449@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Indeed, it seems that multiprocessing uses assertions in many places to handle errors in user code. This could be changed, but it is another task. I can apply the patch, but what about 2.6? it's an incompatible API change, unless we choose to process "lock=None" the same way as "lock=False". _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:53:34 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 02 Dec 2008 21:53:34 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228254814.6.0.531092724198.issue4449@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Does the language guarantee that True and False are singletons (to support the is-test for identity)? Does this API port to Jython and IronPython? Is it a problem that 1 cannot be substituted for True? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:08:59 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 22:08:59 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228255739.83.0.644081364123.issue4449@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The one I know is pypy: bool(x) always return one of the two prebuilt singletons (doubletons?). The docs explicitly mention "If lock is True...", "If lock is False...": http://docs.python.org/library/multiprocessing.html#multiprocessing.sharedctypes.Value I fear that testing the boolean value of the lock variable may have undesired effect; if even the main multiprocessing.RLock object has a _is_zero() method (that seems to return whether the lock is held or not), it is very possible that other implementations choose __nonzero__ for this. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:11:20 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Dec 2008 22:11:20 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228255880.46.0.903725983629.issue4449@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I've changed my mind based on the API change. This should be discussed on the mailing list and deferred until 2.6.2 at least. ---------- resolution: accepted -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:15:50 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 02 Dec 2008 22:15:50 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228256150.21.0.0510304087428.issue4477@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger versions: +Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:20:26 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 22:20:26 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228256426.39.0.255176505046.issue4449@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: What about this other patch: - lock=None has the same semantics as before - lock=True is the same as lock=None (it failed before) - lock=False return the object without the "synchronized" wrap (it failed before) - no need to change previous tests Added file: http://bugs.python.org/file12205/mp_array_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:26:06 2008 From: report at bugs.python.org (John J Lee) Date: Tue, 02 Dec 2008 22:26:06 +0000 Subject: [issue1401] urllib2 302 POST In-Reply-To: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za> Message-ID: <1228256766.89.0.026943807876.issue1401@psf.upfronthosting.co.za> John J Lee added the comment: I think this was actually not a bug, and the fix should not have been applied. I guess this comment is just "for the record", as the fix is probably cruft that can't be removed now, since people will have started relying on it. The only way that the Content-Length header could be in req.headers in the first place is if the user had explicitly requested that it be added (urllib2 adds that header to .unredirected_hdrs, but not to .headers). The user can no doubt provoke all kinds of other errors by adding random HTTP headers -- what makes this particular one special? .add_header() has always been a "you need to know what you're doing, or you'll break stuff" interface, and it's not really possible to "fix" that (at least not without changing the meaning of .add_header()). ---------- nosy: +jjlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:28:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 02 Dec 2008 22:28:33 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1228248426.38.0.442103542843.issue2306@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Tue, Dec 2, 2008 at 12:07 PM, Barry A. Warsaw wrote: > > Barry A. Warsaw added the comment: > > Guido, ETA? I think this will be one of the last things before we can > tag the tree for release. Late tonight. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:57:14 2008 From: report at bugs.python.org (Andrew Paprocki) Date: Tue, 02 Dec 2008 22:57:14 +0000 Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1 In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za> Message-ID: <1228258634.0.0.157436027864.issue4025@psf.upfronthosting.co.za> Andrew Paprocki added the comment: summary of compiler errors/warnings i just hit in the same situation with stock Python-2.6.tgz: >>>>>>>>>>>>>> c++ style comment used "Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 118.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 125.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 130.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 149.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 153.1: 1506-046 (S) Syntax error. & a bunch of other places in unicodeobject.c "Python/_warnings.c", line 380.19: 1506-046 (S) Syntax error. "Python/_warnings.c", line 803.5: 1506-046 (S) Syntax error. >>>>>>>>>>>>>> inline keyword was used "./Modules/signalmodule.c", line 112.1: 1506-277 (S) Syntax error: possible missing ';' or ','? >>>>>>>>>>>>>> other warning "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. ---------- nosy: +apaprocki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:00:12 2008 From: report at bugs.python.org (Andrew Paprocki) Date: Tue, 02 Dec 2008 23:00:12 +0000 Subject: [issue4499] redefinition of TILDE macro on AIX platform In-Reply-To: <1228258808.76.0.068417078821.issue4499@psf.upfronthosting.co.za> Message-ID: <1228258808.76.0.068417078821.issue4499@psf.upfronthosting.co.za> New submission from Andrew Paprocki : "Include/token.h", line 42.9: 1506-236 (W) Macro name TILDE has been redefined. "Include/token.h", line 42.9: 1506-358 (I) "TILDE" is defined on line 250 of /usr/include/sys/ioctl.h. ---------- components: None messages: 76800 nosy: apaprocki severity: normal status: open title: redefinition of TILDE macro on AIX platform type: compile error versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:04:01 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 23:04:01 +0000 Subject: [issue4496] misleading comment in urllib2 In-Reply-To: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za> Message-ID: <1228259041.1.0.0749106191805.issue4496@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: (The change was actually r54138) It seems that this .handlers attribute was used in older versions, before r34922, to close the handlers in-order. IMO it is no more useful, but may be kept for compatibility reasons. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:16:41 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2008 23:16:41 +0000 Subject: [issue4273] cycle created by profile.run In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> Message-ID: <1228259801.93.0.937934537755.issue4273@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Where is the problem, if these reference cycles are properly broken by the garbage collector *unless* you tell it not to? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:43:23 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 02 Dec 2008 23:43:23 +0000 Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1 In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za> Message-ID: <1228261403.61.0.946955365501.issue4025@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: There are still quite a few C99 comments left in the code, esp. in code that's meant for MSVC (which works fine with them) and code for the Mac (which uses gcc and also doesn't have problems with them). Esp. the ctypes and libffi code is full of them. FWIW, this one exists in both SVN trunk and the Python 3.0 branch: ./Modules/_ctypes/callproc.c: -- MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language Personally, I'd find it a lot better to not use C99 style comments in code that's not specifically meant for a C++-capable compiler like MSVC. ---------- nosy: +lemburg versions: +Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:14:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 03 Dec 2008 00:14:40 +0000 Subject: [issue4500] Compiler warnings when compiling Python 3.0 with a C89 compiler In-Reply-To: <1228263280.19.0.817072347743.issue4500@psf.upfronthosting.co.za> Message-ID: <1228263280.19.0.817072347743.issue4500@psf.upfronthosting.co.za> New submission from Christian Heimes : Should / must we do anything about the issue? At least Python builds with a C89 compiler except of ssl and socket module. Those modules include non C89 compliant header files from the OS (bluetooth and tpic). $ LC_ALL="C" CC="gcc -std=c89" make gcc -std=c89 -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/object.o Objects/object.c Objects/object.c: In function 'internal_print': Objects/object.c:295: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result Objects/object.c:304: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result gcc -std=c89 -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/marshal.o Python/marshal.c Python/marshal.c: In function 'w_string': Python/marshal.c:90: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result gcc -std=c89 -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c Modules/main.c: In function 'usage': Modules/main.c:134: warning: format not a string literal and no format arguments Modules/main.c:135: warning: format not a string literal and no format arguments Modules/main.c:136: warning: format not a string literal and no format arguments ---------- assignee: barry components: Interpreter Core messages: 76804 nosy: barry, christian.heimes priority: normal severity: normal stage: test needed status: open title: Compiler warnings when compiling Python 3.0 with a C89 compiler type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:44:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 03 Dec 2008 00:44:28 +0000 Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1 In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za> Message-ID: <1228265068.75.0.532956759594.issue4025@psf.upfronthosting.co.za> Christian Heimes added the comment: Barry, the issue in _ctypes/callproc.c could be a problem for us although Python 2.6 and 3.0 are compiling fine with -std=c89. Should the comment be fixed before the release? ---------- assignee: christian.heimes -> barry nosy: +barry resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:46:44 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 03 Dec 2008 00:46:44 +0000 Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1 In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za> Message-ID: <1228265204.77.0.926959677809.issue4025@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: For 2.6.1, yes you can fix the comments if you can do it now :) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 02:10:55 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 03 Dec 2008 01:10:55 +0000 Subject: [issue4501] asyncore's urgent data management and connection closed events are broken when using poll() In-Reply-To: <1228266655.05.0.188613442109.issue4501@psf.upfronthosting.co.za> Message-ID: <1228266655.05.0.188613442109.issue4501@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : I discovered that some pyftpdlib [1] tests fail when using poll() instead of select(). The problem is in asyncore.readwrite() function which erroneously calls handle_read_event() in case of a POLLPRI event. The patches modify readwrite() function so that: - POLLPRI is now treated as synonym for "there is urgent data to read" so handle_expt_event() is called. - POLLHUP, POLLERR and POLLINVAL are now treated as synonyms for "the connection has been closed" (Twisted behaves exactly the same) so handle_close() is called. Both pyftpdlib and asyncore tests passed on Linux Debian Etch and FreeBSD 7.0-RC1. [1] http://code.google.com/p/pyftpdlib/ ---------- components: Library (Lib) files: asyncore.patch keywords: patch messages: 76807 nosy: giampaolo.rodola, josiah.carlson, josiahcarlson severity: normal status: open title: asyncore's urgent data management and connection closed events are broken when using poll() type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12206/asyncore.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 02:49:37 2008 From: report at bugs.python.org (Conrad.Irwin) Date: Wed, 03 Dec 2008 01:49:37 +0000 Subject: [issue4502] Allowing get_pre_input_hook from Readline In-Reply-To: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za> Message-ID: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za> New submission from Conrad.Irwin : At the moment there is no way of getting the current pre_input_hook out of the readline module, so applications cannot set_pre_input_hook without possibly over-writing users settings (or other parts of the applications settings) I have attached a patch that implements this functionality. It is probably not very useful in many situations, but I am now using it to maintain my normal custom auto-indenting python prompt in a library that allows me to edit arbitrary strings using readline. A better way to implement this might be to ---------- components: Library (Lib) files: readline.c.diff keywords: patch messages: 76808 nosy: Conrad.Irwin severity: normal status: open title: Allowing get_pre_input_hook from Readline versions: Python 2.5 Added file: http://bugs.python.org/file12207/readline.c.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 02:50:51 2008 From: report at bugs.python.org (Conrad.Irwin) Date: Wed, 03 Dec 2008 01:50:51 +0000 Subject: [issue4502] Allowing get_pre_input_hook from Readline In-Reply-To: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za> Message-ID: <1228269051.81.0.946090113021.issue4502@psf.upfronthosting.co.za> Changes by Conrad.Irwin : ---------- type: -> feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 02:51:50 2008 From: report at bugs.python.org (Conrad.Irwin) Date: Wed, 03 Dec 2008 01:51:50 +0000 Subject: [issue4502] Allowing get_pre_input_hook from Readline In-Reply-To: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za> Message-ID: <1228269110.41.0.391921190985.issue4502@psf.upfronthosting.co.za> Conrad.Irwin added the comment: ...wrap the current readline in a pure python module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 04:46:32 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 03 Dec 2008 03:46:32 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228275992.45.0.31849435194.issue4477@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Jeffrey, I've run my own timings and verified the improvement. Please go ahead and apply the trunk (2.7 head). It's too late for 3.0 but once that is out the door, Barry has approved adding the patch for 3.0.1. ---------- assignee: rhettinger -> jyasskin resolution: -> accepted stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 05:09:03 2008 From: report at bugs.python.org (darrenr) Date: Wed, 03 Dec 2008 04:09:03 +0000 Subject: [issue4273] cycle created by profile.run In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> Message-ID: <1228277343.51.0.238079768079.issue4273@psf.upfronthosting.co.za> darrenr added the comment: I work at a development house that has decided to tell gc to keep all cycles, in order to prevent any cycles from being created at all. It's analogous to the policy of keeping a C++ build warning-free. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 05:40:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 03 Dec 2008 04:40:20 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228279220.41.0.432885502737.issue4335@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 05:43:11 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 03 Dec 2008 04:43:11 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za> Message-ID: <1228279391.8.0.954310465682.issue2306@psf.upfronthosting.co.za> Guido van Rossum added the comment: I wouldn't go so far as claiming this is completed, but I think it's in a good enough shape to release. I may continue to work on it some more, but you can freeze the tree at any moment -- I won't add more XXX stuff (except perhaps commented-out). Review of what I submitted is also very welcome. I'll try to get back on IRC. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 06:00:12 2008 From: report at bugs.python.org (Thomas Lee) Date: Wed, 03 Dec 2008 05:00:12 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1228280412.11.0.489718307659.issue4347@psf.upfronthosting.co.za> Thomas Lee added the comment: Thanks for the review Brett, apologies for the mess. I'm attaching two new patches -- one for review, the other containing the generated files. These differ very slightly from the original patch -- mainly just removing some stuff I don't think is necessary. You're probably aware of this, but it's important for the changes to the generated files to be checked in too -- likewise for testing the patch. Added file: http://bugs.python.org/file12208/build-evilness-fix-03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 06:00:40 2008 From: report at bugs.python.org (Thomas Lee) Date: Wed, 03 Dec 2008 05:00:40 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1228280440.6.0.010604116745.issue4347@psf.upfronthosting.co.za> Thomas Lee added the comment: And here's the patch for review. Added file: http://bugs.python.org/file12209/build-evilness-fix-03-review.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 06:03:57 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 03 Dec 2008 05:03:57 +0000 Subject: [issue4331] Can't use _functools.partial() created function as method In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za> Message-ID: <1228280637.0.0.888400405518.issue4331@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 06:59:24 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 03 Dec 2008 05:59:24 +0000 Subject: [issue4500] Compiler warnings when compiling Python 3.0 with a C89 compiler In-Reply-To: <1228263280.19.0.817072347743.issue4500@psf.upfronthosting.co.za> Message-ID: <1228283964.03.0.0305935089024.issue4500@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What operating system is this on? In any case, the warnings look harmless. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 07:54:16 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Wed, 03 Dec 2008 06:54:16 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1228287256.78.0.44311451222.issue4477@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Thanks for the review, Raymond. Committed to the trunk in r67494. I'll svnmerge it over to 3.0.1 once Barry unfreezes the branches. Martin, let me know if you analyze this any more and find anything interesting. ---------- stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 10:36:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Dec 2008 09:36:18 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1228279391.8.0.954310465682.issue2306@psf.upfronthosting.co.za> Message-ID: <1228296969.9481.22.camel@localhost> Antoine Pitrou added the comment: Some small mistakes : * ? an object always compares equal to itself (i.e., ``x is y`` implies ``x == y``; this is true even for *NaN*) ?. Actually NaN is not equal to itself: True >>> f == f False * ? The traceback printed when an unhandled exception occurs walks the chain of :attr:`__cause__` and :attr:`__context__` attributes and prints a separate traceback for each component of the chain, with the primary exception at the top. ? If by "primary exception" you mean the latest one, then it's printed at the bottom, not the top. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 10:47:09 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 09:47:09 +0000 Subject: [issue4497] Compiler warnings in longobject.c In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> Message-ID: <1228297629.86.0.440555038849.issue4497@psf.upfronthosting.co.za> Mark Dickinson added the comment: This is on Windows, right? I don't know of any other platforms where __int64 is defined. At a first glance, it looks as though the code's correct, so we probably just need to add some casts to silence the compiler. I'll add them to the patch in issue 4393 and check it in sometime soon after 3.0 is released. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 10:48:11 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 09:48:11 +0000 Subject: [issue4497] Compiler warnings in longobject.c In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> Message-ID: <1228297691.1.0.598550086859.issue4497@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: +Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 10:50:49 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 03 Dec 2008 09:50:49 +0000 Subject: [issue4500] Compiler warnings when compiling Python 3.0 with a C89 compiler In-Reply-To: <1228263280.19.0.817072347743.issue4500@psf.upfronthosting.co.za> Message-ID: <1228297849.5.0.767869065971.issue4500@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm Ubuntu 8.10 AMD64. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 10:53:04 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 03 Dec 2008 09:53:04 +0000 Subject: [issue4273] cycle created by profile.run In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> Message-ID: <1228297984.45.0.482783144125.issue4273@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: But the garbage collector was invented for this very purpose: to break cycles! Take the following example which create a cycle for every instance of the class (the profile module has similar code): class C: def __init__(self): self.action = self.action_GO # cycle: the object's dict now contains a bound method # which references the object def action_GO(self): print("GO") This kind of construct is useful, and probably the best one in some cases. Would you ban it from your code? from the python standard library? Reference cycles are not bad at all, as long as they only hold memory: they will be reclaimed when the systems needs more memory. I agree that they can be a problem for other valuable resource: opened files, sockets, database cursors... even one thousand of uncollected sockets are not enough to trigger a collection. For this usage, I suggest that you iterate over gc.garbage, only warn for such objects and remove all others (and after, clear gc.garbage and run gc.collect() without the debug flag) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 10:54:42 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 09:54:42 +0000 Subject: [issue4393] Portability fixes in longobject.c In-Reply-To: <1227443306.12.0.492255652415.issue4393@psf.upfronthosting.co.za> Message-ID: <1228298082.92.0.956675312261.issue4393@psf.upfronthosting.co.za> Mark Dickinson added the comment: See also issue 4497 for some compiler warnings that need to be silenced. ---------- assignee: -> marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 11:20:04 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 03 Dec 2008 10:20:04 +0000 Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1 In-Reply-To: <1228265068.75.0.532956759594.issue4025@psf.upfronthosting.co.za> Message-ID: <49365D4E.60106@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-03 01:44, Christian Heimes wrote: > Christian Heimes added the comment: > > Barry, the issue in _ctypes/callproc.c could be a problem for us > although Python 2.6 and 3.0 are compiling fine with -std=c89. Should the > comment be fixed before the release? I had a second look at the code. That comment is in #ifdefs: #ifdef MS_WIN32 ... #endif so it won't affect compiling ctypes on Unix platforms. Still, I find the situation with C99 comments scattered around the source code less than ideal. Either we officially abandon C90 and move on to C99 or we stick to C90 for all source code (including code that only gets compiled on Macs or MSVC). It's just too easy for a C99 comment to slip into code that's targeted for non-gcc/non-MSVC compilers as well and these then break the portability of Python to those compilers/platforms. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 11:31:53 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 03 Dec 2008 10:31:53 +0000 Subject: [issue4503] exception traceback sometimes slow In-Reply-To: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za> Message-ID: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Please try this code. import zipfile zipfile.PyZipFile("foobar") I'm not sure this is problematic or not. ---------- messages: 76823 nosy: ocean-city severity: normal status: open title: exception traceback sometimes slow versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 12:23:48 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Dec 2008 11:23:48 +0000 Subject: [issue4503] exception traceback sometimes slow In-Reply-To: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za> Message-ID: <1228303428.17.0.030276990603.issue4503@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What do you mean by "slow"? I can't reproduce under Linux. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 13:20:41 2008 From: report at bugs.python.org (ganges master) Date: Wed, 03 Dec 2008 12:20:41 +0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1228306841.59.0.485406172017.issue1615@psf.upfronthosting.co.za> ganges master added the comment: here's a short example of the bug >>> class Foo(object): ... def __getattr__(self, name): ... return 42 ... @property ... def bacon(self): ... return int.lalala ... @property ... def eggs(self): ... return 17 ... >>> f = Foo() >>> f.bacon # raises an AttributeError, and silently ignores it 42 >>> f.eggs 17 >>> are there any news in this front? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 13:48:44 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 03 Dec 2008 12:48:44 +0000 Subject: [issue4503] exception traceback sometimes slow In-Reply-To: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za> Message-ID: <1228308524.46.0.713639203427.issue4503@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Traceback (most recent call last): File "a.py", line 4, in zipfile.PyZipFile("foobar") File "e:\python-dev\py3k\lib\zipfile.py", line 683, in __init__ self.fp = io.open(file, modeDict[mode]) File "e:\python-dev\py3k\lib\io.py", line 222, in open closefd) File "e:\python-dev\py3k\lib\io.py", line 615, in __init__ _fileio._FileIO.__init__(self, name, mode, closefd) IOError: [Errno 2] No such file or directory: 'foobar' [33393 refs] For example, some delay after File "e:\python-dev\py3k\lib\zipfile.py", line 683, in __init__ this line. I don't know why, but maybe because current io module is not written in C. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 14:54:21 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 03 Dec 2008 13:54:21 +0000 Subject: [issue4503] exception traceback sometimes slow In-Reply-To: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za> Message-ID: <1228312461.76.0.0597500287923.issue4503@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Is "e:" a network drive? This could explain the delay. But it's true that the code that displays the exception has to call readline() 683 times, and this code is written in python. There is a project to rewrite io.py in C... Also, you are using a debug build. Is the slowdown still noticeable with a release build? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 16:12:31 2008 From: report at bugs.python.org (Kandalintsev Alexandre) Date: Wed, 03 Dec 2008 15:12:31 +0000 Subject: [issue4504] Doc/includes out of date In-Reply-To: <1228317151.0.0.247263497976.issue4504@psf.upfronthosting.co.za> Message-ID: <1228317151.0.0.247263497976.issue4504@psf.upfronthosting.co.za> New submission from Kandalintsev Alexandre : Hello! Doc/includes/noddy.c and all other uses Py_InitModule3 which is removed from py3k. noddy2.c doesn't compile("noddy2.c:16: error: ?Noddy? has no member named ?ob_type?"). ---------- assignee: georg.brandl components: Documentation messages: 76828 nosy: exe, georg.brandl severity: normal status: open title: Doc/includes out of date type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 17:13:50 2008 From: report at bugs.python.org (Kandalintsev Alexandre) Date: Wed, 03 Dec 2008 16:13:50 +0000 Subject: [issue4505] ob_size not removed from docs In-Reply-To: <1228320830.04.0.998447040323.issue4505@psf.upfronthosting.co.za> Message-ID: <1228320830.04.0.998447040323.issue4505@psf.upfronthosting.co.za> New submission from Kandalintsev Alexandre : Hello! In http://docs.python.org/dev/3.0/extending/newtypes.html we see ob_size in object definition. But if we are look on PyTypeObject in ./Include/object.h we will find that there no ob_size defined. So we must remove this string from noddy_NoddyType definition or segfault will occur: 0, /*ob_size*/ ---------- assignee: georg.brandl components: Documentation messages: 76829 nosy: exe, georg.brandl severity: normal status: open title: ob_size not removed from docs versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 17:29:44 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 03 Dec 2008 16:29:44 +0000 Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za> Message-ID: <1228321784.3.0.933965055938.issue3890@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Wouldn't it be better to fix this before 3.0 gets released? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 17:31:40 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 03 Dec 2008 16:31:40 +0000 Subject: [issue1541] Bad OOB data management when using asyncore with select.poll() In-Reply-To: <1196618056.9.0.300104478176.issue1541@psf.upfronthosting.co.za> Message-ID: <1228321900.63.0.0501937369218.issue1541@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: This is a duplicate of #4501 which provides a better patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 17:45:48 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 03 Dec 2008 16:45:48 +0000 Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za> Message-ID: <1228322748.48.0.45962899673.issue3890@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I fear that is is too late for 3.0: the branch is already "frozen", except maybe for special cases. In any case a patch is needed. I am not a ssl expert, I just implemented the "let SSL_ERROR_WANT_READ propagate". Please review. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file12210/ssl_noblock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 18:22:37 2008 From: report at bugs.python.org (Andrew Paprocki) Date: Wed, 03 Dec 2008 17:22:37 +0000 Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1 In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za> Message-ID: <1228324957.12.0.161073451075.issue4025@psf.upfronthosting.co.za> Andrew Paprocki added the comment: The list of files/lines I posted yesterday was all that I had to change to get it to build here (where a C++ style comment is a syntax error), so it doesn't seem like a massive change. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 18:42:39 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 03 Dec 2008 17:42:39 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1228296969.9481.22.camel@localhost> Message-ID: Guido van Rossum added the comment: On Wed, Dec 3, 2008 at 1:36 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Some small mistakes : > > * ? an object always compares equal to itself (i.e., ``x is y`` implies > ``x == y``; this is true even for *NaN*) ?. Actually NaN is not equal to > itself: > > True >>>> f == f > False Raymond pointed this out too and I fixed it before Barry got to the tagging. > * ? The traceback printed when an unhandled exception occurs walks the > chain of :attr:`__cause__` and :attr:`__context__` attributes and prints > a separate traceback for each component of the chain, with the primary > exception at the top. ? If by "primary exception" you mean the latest > one, then it's printed at the bottom, not the top. No, I mean the first one (as the example tries to clarify). Thanks for reviewing! I definitely cut it too close this time, due to various other commitments. :-( _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 18:48:24 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 03 Dec 2008 17:48:24 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za> Message-ID: <1228326504.28.0.835053458926.issue2306@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think this is good enough for now. Someone else can help add stuff I missed, but I don't think we need to keep a bug open to remind us. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 18:59:09 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 03 Dec 2008 17:59:09 +0000 Subject: [issue4503] exception traceback sometimes slow In-Reply-To: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za> Message-ID: <1228327149.34.0.669422983193.issue4503@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: No, e: is not netword drive. It's another partition on hard drive. But my machine is pretty slow. >Also, you are using a debug build. Is the slowdown still noticeable with >a release build? I tried release build(VC6), and was much faster. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 21:28:51 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 03 Dec 2008 20:28:51 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za> Message-ID: <1228336131.23.0.661121355447.issue4201@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 21:29:01 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 03 Dec 2008 20:29:01 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1228336141.73.0.902001597141.issue4197@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 21:29:22 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 03 Dec 2008 20:29:22 +0000 Subject: [issue4223] inspect.getsource doesn't work on functions imported from a zipfile In-Reply-To: <1225214386.69.0.0480331344152.issue4223@psf.upfronthosting.co.za> Message-ID: <1228336162.36.0.0793409717434.issue4223@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 21:49:29 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 03 Dec 2008 20:49:29 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1228337369.88.0.669264907539.issue4197@psf.upfronthosting.co.za> Nick Coghlan added the comment: runpy needs a non-standard PEP 302 extension to set __file__ correctly in the modules it runs. The pkgutil stuff it uses to find pure Python modules in the filesystem supports that extension, but zipimport doesn't (yet). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 21:51:36 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 03 Dec 2008 20:51:36 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za> Message-ID: <1228337496.39.0.289790222368.issue4201@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just to confirm - this is specific to __main__.py right? The problem is actually with runpy not being able to set __file__ correctly, rather than being pdb specific. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:00:24 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 03 Dec 2008 21:00:24 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <18742.62305.106334.384352@montanaro-dyndns-org.local> New submission from Skip Montanaro : I downloaded the 3.0 tarfile and did a straightforward configure make make test on Solaris 10 and got several test failures: 290 tests OK. 4 tests failed: test_cmath test_math test_posix test_subprocess Here's the output for just the failing tests: test test_cmath failed -- Traceback (most recent call last): File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_cmath.py", line 336, in test_specific_values self.fail('OverflowError not raised in test %s' % test_str) AssertionError: OverflowError not raised in test exp0052: exp(complex(710.0, 1.5)) test test_math failed -- errors occurred; run in verbose mode for details test test_posix failed -- Traceback (most recent call last): File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_posix.py", line 252, in test_getcwd_long_pathnames support.rmtree(base_path) File "/home/tuba/skipm/src/Python-3.0/Lib/test/support.py", line 98, in rmtree shutil.rmtree(path) File "/home/tuba/skipm/src/Python-3.0/Lib/shutil.py", line 225, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "/home/tuba/skipm/src/Python-3.0/Lib/shutil.py", line 223, in rmtree os.rmdir(path) OSError: [Errno 22] Invalid argument: '/home/tuba/skipm/src/Python-3.0/@test.getcwd' Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Fatal Python error: Py_Initialize: can't initialize sys standard streams ImportError: No module named encodings.utf_8 . this bit of output is from a test of stdout in a different process ... test test_subprocess failed -- Traceback (most recent call last): File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_subprocess.py", line 115, in test_executable self.assertEqual(p.returncode, 47) AssertionError: -6 != 47 Here's the test_math output run through regrtest with the -v option: ====================================================================== FAIL: testLog (test.test_math.MathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_math.py", line 510, in testLog self.assertRaises(ValueError, math.log, NINF) AssertionError: ValueError not raised by log ====================================================================== FAIL: testLog10 (test.test_math.MathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_math.py", line 532, in testLog10 self.assertRaises(ValueError, math.log10, NINF) AssertionError: ValueError not raised by log10 ---------------------------------------------------------------------- Ran 39 tests in 0.294s Skip ---------- messages: 76839 nosy: skip.montanaro severity: normal status: open title: 3.0 make test failures on Solaris 10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:07:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:07:59 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228338479.18.0.72397315687.issue4506@psf.upfronthosting.co.za> Mark Dickinson added the comment: I think you brought up the math and cmath errors before, and I never managed to get to the bottom of the problem. I'll have another go. I don't think the (c)math test failures should be regarded as terribly serious, though; the tests are quite ridiculously strict. Could you please tell me what cmath.exp(complex(710.0, 1.5)) actually returns, if it doesn't raise OverflowError? (Don't know nuffin about posix and subprocess.) ---------- nosy: +marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:13:36 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 03 Dec 2008 21:13:36 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <1228338479.18.0.72397315687.issue4506@psf.upfronthosting.co.za> Message-ID: <18742.63101.946418.315058@montanaro-dyndns-org.local> Skip Montanaro added the comment: Mark> I think you brought up the math and cmath errors before, and I Mark> never managed to get to the bottom of the problem. I'll have Mark> another go. I vaguely remember something about that. If I can be a "test mule" for you, let me know. Mark> Could you please tell me what Mark> cmath.exp(complex(710.0, 1.5)) Mark> actually returns, if it doesn't raise OverflowError? (1.5802653829857376e+307+inf*j) Maybe it needs to overflow along both axes??? S _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:14:06 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 03 Dec 2008 21:14:06 +0000 Subject: [issue4507] 3.0 test failure on Mac OS X 10.5.5 In-Reply-To: <18742.63130.521395.761295@montanaro-dyndns-org.local> Message-ID: <18742.63130.521395.761295@montanaro-dyndns-org.local> New submission from Skip Montanaro : After seeing test failures on Solaris 10 (issue4506) I decided to give Mac OS X a whirl. Got one test failure: test test_cmd_line failed -- Traceback (most recent call last): File "/Users/skip/src/Python-3.0/Lib/test/test_cmd_line.py", line 143, in test_run_code 0) AssertionError: 1 != 0 Skip ---------- messages: 76842 nosy: skip.montanaro severity: normal status: open title: 3.0 test failure on Mac OS X 10.5.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:30:25 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:30:25 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228339825.17.0.783504500876.issue4506@psf.upfronthosting.co.za> Mark Dickinson added the comment: > (1.5802653829857376e+307+inf*j) Those values look right; except that there's some code near the end of the cexp function that's supposed to set errno to ERANGE if either the real or imaginary component of the result is infinity (and then math_1 knows to raise OverflowError as a result). It looks like that's not happening for some reason. If you have time, could you try the attached patch and report what gets printed when cmath.exp(710+1.5j) is called? On my machine, I get: Python 3.1a0 (py3k:67510M, Dec 3 2008, 20:56:19) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import cmath >>> cmath.exp(710.0 + 1.5j) r.real, r.imag: 1.58027e+307, inf Py_IS_INFINITY(r.real), Py_IS_INFINITY(r.imag): 0, 1 Traceback (most recent call last): File "", line 1, in OverflowError: math range error Mark ---------- keywords: +patch Added file: http://bugs.python.org/file12211/cmath_debug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:34:57 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:34:57 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228340097.66.0.484142709153.issue4506@psf.upfronthosting.co.za> Changes by Mark Dickinson : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:35:24 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:35:24 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228340124.08.0.758266221112.issue4506@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- keywords: +64bit -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:35:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:35:59 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228340159.08.0.822925012306.issue4506@psf.upfronthosting.co.za> Changes by Mark Dickinson : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:36:42 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:36:42 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228340202.32.0.587995204152.issue4506@psf.upfronthosting.co.za> Changes by Mark Dickinson : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:40:30 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:40:30 +0000 Subject: [issue4507] 3.0 test failure on Mac OS X 10.5.5 In-Reply-To: <18742.63130.521395.761295@montanaro-dyndns-org.local> Message-ID: <1228340430.45.0.520264116061.issue4507@psf.upfronthosting.co.za> Mark Dickinson added the comment: This looks like a duplicate of issue 4388. ---------- nosy: +marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:41:33 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:41:33 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228340493.09.0.26218820452.issue4506@psf.upfronthosting.co.za> Changes by Mark Dickinson : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:43:22 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:43:22 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228340602.93.0.444238034542.issue4506@psf.upfronthosting.co.za> Mark Dickinson added the comment: Tracker issue: I don't seem to be able to remove the 'patch' keyword without (accidentally) ending up with something else---in this case the 64bit keyword. Is this just me being incompetent, or should I file a tracker bug? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:48:44 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 03 Dec 2008 21:48:44 +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: <1228340924.12.0.83274462488.issue1028@psf.upfronthosting.co.za> Guilherme Polo added the comment: I've been working on a new _tkinter (named it as "plumage") these days and I hit this same problem for trusting too much that nothing from tcl, including tk and extensions, would give me this embedded null. Checking another bridge to Tcl (one done for Perl) it is possible to notice that it also chose to verify for these bytes and convert them to something else, a 0. The code for this for Python can be found at http://code.google.com/p/plumage/source/browse/trunk/src/utils.c#42 up to line 76, it could/should be adapted to the _tkinter in py3k and also for python 2.x. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:58:06 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 03 Dec 2008 21:58:06 +0000 Subject: [issue4497] Compiler warnings in longobject.c In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> Message-ID: <1228341486.7.0.806324350329.issue4497@psf.upfronthosting.co.za> Mark Dickinson added the comment: Raymond, could you please try the attached patch to see if it silences the compiler? ---------- keywords: +patch Added file: http://bugs.python.org/file12212/issue4497.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:58:57 2008 From: report at bugs.python.org (Brian Thorne) Date: Wed, 03 Dec 2008 21:58:57 +0000 Subject: [issue4508] distutils compiler not handling spaces in path to output/src files In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za> Message-ID: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za> New submission from Brian Thorne : I found this bug when using scipy's weave and having some inline C/C++ code. Weave uses distutils to compile the source in its own directory, python was installed under "program files". Unfortunately it doesn't seem to handle spaces in the path to either the output or the temporary source files. I checked that this was the only problem by copying the weave directory from site-packages and put it in another directory without spaces in the path - weave and distutils then worked fine. I then tried the g++ command seen in the stack trace at the command line and got the same error - so altered the command by correctly quoting the -c "path/to source/a.c" and the -o objects. This worked so set out changing it in distutils. The two files I altered were unixcompiler.py (surprising as I am under windows!) and cygwinccompiler.py This was clearly an older stable build so I checked out the python trunk r67510 on windows (32bit), made a patch, and tested with my weave dependant code. (I am not familiar enough with distutils to make a standalone test). The same method to cause a problem has the same effect in ubuntu - the build directory seems to default to users home, but as the source path has a space in it g++ gets confused. ---------- components: Distutils files: distutils_compiler_quoting.patch keywords: patch messages: 76848 nosy: Thorney severity: normal status: open title: distutils compiler not handling spaces in path to output/src files type: behavior versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12213/distutils_compiler_quoting.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 23:06:38 2008 From: report at bugs.python.org (gumpy) Date: Wed, 03 Dec 2008 22:06:38 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> New submission from gumpy : I'm unsure of the expected behavior in this case but it seems odd. The bytearray in the following example can be resized to a length of 5-10 bytes without throwing an exception. Python 3.0rc3 (r30rc3:67312, Dec 3 2008, 10:38:14) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 >>> b = bytearray(b'x' * 10) >>> v = memoryview(b) >>> b[:] = b'y' * 11 Traceback (most recent call last): File "", line 1, in BufferError: Existing exports of data: object cannot be re-sized >>> b[:] = b'y' * 5 >>> b bytearray(b'yyyyy') >>> v.tobytes() b'yyyyy\x00xxxx' >>> v2 = memoryview(b) >>> v2.tobytes() b'yyyyy' ---------- components: Interpreter Core messages: 76849 nosy: gumpy severity: normal status: open title: possible memoryview bug type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:02:09 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 03 Dec 2008 23:02:09 +0000 Subject: [issue4497] Compiler warnings in longobject.c In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> Message-ID: <1228345329.57.0.549246783331.issue4497@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes, the compiler is happy now. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:28:29 2008 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 03 Dec 2008 23:28:29 +0000 Subject: [issue4384] Add a warnings.showwarning replacement for logging In-Reply-To: <1227309698.77.0.511874051241.issue4384@psf.upfronthosting.co.za> Message-ID: <1228346909.41.0.184738153778.issue4384@psf.upfronthosting.co.za> Vinay Sajip added the comment: Checked into trunk, r67511. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:35:59 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 03 Dec 2008 23:35:59 +0000 Subject: [issue2350] 'exceptions' import fixer In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za> Message-ID: <1228347359.17.0.47498830139.issue2350@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:38:38 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 03 Dec 2008 23:38:38 +0000 Subject: [issue4510] ValueError for list.remove() not very helpful In-Reply-To: <1228347518.63.0.0108612017272.issue4510@psf.upfronthosting.co.za> Message-ID: <1228347518.63.0.0108612017272.issue4510@psf.upfronthosting.co.za> New submission from Brett Cannon : If you try to remove something from a list, e.g. ``[].remove(1)``, the message from ValueError is rather useless: "ValueError: list.remove(x): x not in list". It should probably list the repr for the argument to help in debugging. ---------- keywords: easy messages: 76852 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: ValueError for list.remove() not very helpful type: behavior versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:56:29 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 03 Dec 2008 23:56:29 +0000 Subject: [issue1025540] urllib2 http auth Message-ID: <1228348589.62.0.854459043131.issue1025540@psf.upfronthosting.co.za> Gregory P. Smith added the comment: this should be trivial to implement (other than urllib and urllib2 being a giant mess). adding to my queue. ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:58:24 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 03 Dec 2008 23:58:24 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1228337496.39.0.289790222368.issue4201@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: No, I only used __main__.py to make it easy to reproduce the problem. Pdb will not be able to access code in any module with a custom __loader__. For example, if you move f() to foo.py inside test.zip and import it from __main__, you will see the same issue. My patch gives linecache.getlines() called by Pdb access to module's globs and thus to its __loader__ . It has nothing to do with runpy. > The problem is actually with runpy not being able to set __file__ > correctly, rather than being pdb specific. You must be thinking issue4197 where two distinct problems are adressed: first, the crash due to __file__ set to None by runpy and second, missing globs parameter to linecache.getlines() in doctest module. My patch, doctest-1.patch works around the first issue and fixes the second. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:02:25 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 04 Dec 2008 00:02:25 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1228348945.71.0.990252939299.issue1424152@psf.upfronthosting.co.za> Gregory P. Smith added the comment: We need make sure this happens for 2.7/3.1. As its large enough to be a new feature it won't make it into 2.4/2.5/2.6/3.0. ---------- nosy: +gregory.p.smith priority: normal -> high versions: +Python 2.7, Python 3.1 -Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:03:55 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 04 Dec 2008 00:03:55 +0000 Subject: [issue4140] urllib2: request with digest auth through proxy fail In-Reply-To: <1224258333.01.0.331002758914.issue4140@psf.upfronthosting.co.za> Message-ID: <1228349035.36.0.488805594987.issue4140@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith priority: -> normal versions: +Python 2.7, Python 3.1 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:06:37 2008 From: report at bugs.python.org (Senthil) Date: Thu, 04 Dec 2008 00:06:37 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1228349197.99.0.676698938821.issue1424152@psf.upfronthosting.co.za> Senthil added the comment: I agree, gregory. I had verified the fix and supplied patch for py2.6 and py3K. If those still apply to the trunk, I think we should go ahead, otherwise I shall come with the new patch for 2.7/3k. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:28:34 2008 From: report at bugs.python.org (K. C. Wong) Date: Thu, 04 Dec 2008 00:28:34 +0000 Subject: [issue4511] Decorators should have an index entry In-Reply-To: <1228350514.36.0.487340593327.issue4511@psf.upfronthosting.co.za> Message-ID: <1228350514.36.0.487340593327.issue4511@psf.upfronthosting.co.za> New submission from K. C. Wong : While decorators have been introduced since Python 2.4, there continues to be no index reference to it in the Python Language Reference. Given this being a major language feature, I think it is an oversight. ---------- assignee: georg.brandl components: Documentation messages: 76857 nosy: dvusboy, georg.brandl severity: normal status: open title: Decorators should have an index entry type: feature request versions: Python 2.4, Python 2.5, Python 2.5.3, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:34:25 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 00:34:25 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za> Message-ID: <1228350865.63.0.396058259726.issue4201@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Off-topic: How to report a bug tracker bug? The e-mail I sent in response to Nick's post started with: """ On Wed, Dec 3, 2008 at 3:51 PM, Nick Coghlan wrote: > Just to confirm - this is specific to __main__.py right? > No, I only used __main__.py to make it easy to reproduce the problem. ... """ But the first two lines got eaten by the tracker. Should I open an issue here and if so, what do I set as a component? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:43:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 00:43:20 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : >From issue4197: """ runpy needs a non-standard PEP 302 extension to set __file__ correctly in the modules it runs. The pkgutil stuff it uses to find pure Python modules in the filesystem supports that extension, but zipimport doesn't (yet). """ -- Nick Coghlan I am working on a patch. ---------- components: Extension Modules messages: 76859 nosy: belopolsky severity: normal status: open title: Add get_filename method to zipimport type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:44:57 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 00:44:57 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1228351497.05.0.940381368409.issue4197@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I created issue4512 to implement get_filename extension in zipimport. Will post a patch shortly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:45:30 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 00:45:30 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1228351530.45.0.597176863934.issue4512@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 02:23:01 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 04 Dec 2008 01:23:01 +0000 Subject: [issue1581476] Text search gives bad count if called from variable trace Message-ID: <1228353781.42.0.197579233669.issue1581476@psf.upfronthosting.co.za> Guilherme Polo added the comment: This is indeed a problem with Tkinter only, but I didn't check what is causing it yet. For the suggestion about fixing the search method regarding the pattern: the fix is almost fine, but we need to disallow None as a pattern. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 02:36:43 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 01:36:43 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1228354603.78.0.667787991692.issue4512@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- keywords: +patch Added file: http://bugs.python.org/file12214/zipimport.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 02:52:43 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Dec 2008 01:52:43 +0000 Subject: [issue4513] Finish updating zip docstring In-Reply-To: <1228355563.66.0.943103489594.issue4513@psf.upfronthosting.co.za> Message-ID: <1228355563.66.0.943103489594.issue4513@psf.upfronthosting.co.za> New submission from Terry J. Reedy : >>> help(zip) #3.0 class zip(object) | zip(iter1 [,iter2 [...]]) --> zip object | | Return a zip object whose .__next__() method ... StopIteration. | Works like the zip() | function but consumes less memory by returning an iterator instead of | a list. The last sentence is left over from when 3.0 zip was itertools.izip. Just delete it. ---------- assignee: georg.brandl components: Documentation messages: 76862 nosy: georg.brandl, tjreedy severity: normal status: open title: Finish updating zip docstring versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 03:01:30 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 02:01:30 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1228356090.53.0.366601380578.issue4512@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I have attached a rough patch implementing the get_filename. I deliberately copied code from get_source method that finds the filename inside the zip archive and simply prefixed that with the archive path. I could not find any detailed discussion of what get_filename is supposed to do. Pkgutil's get_filename is not documented and not unit- tested. Google search revealed an old thread at , but it only says """ >runpy needs a get_filename() method, so it knows what to set __file__ too - >currently its emulation supports that, but it isn't officially part of the >PEP >302 API. It sounds like maybe a new PEP is needed to document all the extensions to the importer/loader protocols. :( """ I don't think a brand new PEP is needed, but an amendment to PEP 302 would be helpful. Nick, do you have any notes on what get_filename should do in various cases? My implementation fixes one of the problems in issue4197: $ ./python.exe testmodule.zip ********************************************************************** File "testmodule.zip/__main__.py", line ?, in __main__.c Failed example: 'line 2' Expected nothing Got: 'line 2' ********************************************************************** 1 items had failures: 1 of 1 in __main__.c ***Test Failed*** 1 failures. Note that line number is still reported as '?', but there is no crash. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 03:04:24 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 04 Dec 2008 02:04:24 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1228356264.87.0.168865227975.issue4303@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 03:04:43 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 04 Dec 2008 02:04:43 +0000 Subject: [issue1683] Thread local storage and PyGILState_* mucked up by os.fork() In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za> Message-ID: <1228356283.25.0.558685105513.issue1683@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 03:04:57 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 04 Dec 2008 02:04:57 +0000 Subject: [issue4469] CVE-2008-5031 multiple integer overflows In-Reply-To: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za> Message-ID: <1228356297.43.0.240941938898.issue4469@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 04:15:19 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 04 Dec 2008 03:15:19 +0000 Subject: [issue4514] test_binascii is failing In-Reply-To: <1228360519.8.0.091239531214.issue4514@psf.upfronthosting.co.za> Message-ID: <1228360519.8.0.091239531214.issue4514@psf.upfronthosting.co.za> New submission from Raymond Hettinger : test_binascii.py fails because crc32 accepts a string. >From my WindowsXP box: C:\Python30>python \python30\lib\test\test_binascii.py test_base64invalid (__main__.BinASCIITest) ... ok test_base64valid (__main__.BinASCIITest) ... ok test_crc32 (__main__.BinASCIITest) ... ok test_empty_string (__main__.BinASCIITest) ... ok test_exceptions (__main__.BinASCIITest) ... ok test_functions (__main__.BinASCIITest) ... ok test_hex (__main__.BinASCIITest) ... ok test_no_binary_strings (__main__.BinASCIITest) ... FAIL test_qp (__main__.BinASCIITest) ... ok test_uu (__main__.BinASCIITest) ... ok ====================================================================== FAIL: test_no_binary_strings (__main__.BinASCIITest) ---------------------------------------------------------------------- Traceback (most recent call last): File "\python30\lib\test\test_binascii.py", line 177, in test_no_binary_strings self.assertRaises(TypeError, f, "test") AssertionError: TypeError not raised by crc32 ---------------------------------------------------------------------- Ran 10 tests in 0.016s FAILED (failures=1) Traceback (most recent call last): File "\python30\lib\test\test_binascii.py", line 183, in test_main() File "\python30\lib\test\test_binascii.py", line 180, in test_main support.run_unittest(BinASCIITest) File "C:\Python30\lib\test\support.py", line 698, in run_unittest _run_suite(suite) File "C:\Python30\lib\test\support.py", line 681, in _run_suite raise TestFailed(err) test.support.TestFailed: Traceback (most recent call last): File "\python30\lib\test\test_binascii.py", line 177, in test_no_binary_strings self.assertRaises(TypeError, f, "test") AssertionError: TypeError not raised by crc32 ---------- assignee: loewis components: Extension Modules messages: 76864 nosy: loewis, rhettinger severity: normal status: open title: test_binascii is failing versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 04:46:55 2008 From: report at bugs.python.org (Peter Wang) Date: Thu, 04 Dec 2008 03:46:55 +0000 Subject: [issue4515] Formatting error in "What's New in Python 3.0" In-Reply-To: <1228362415.59.0.446802801045.issue4515@psf.upfronthosting.co.za> Message-ID: <1228362415.59.0.446802801045.issue4515@psf.upfronthosting.co.za> New submission from Peter Wang : In the section "Removed Syntax", there is some ReST markup that leaked through into the output: "The only acceptable syntax for relative imports is from .``[*module*] :keyword:`import` *name*; :keyword:`import` forms not starting with ``. are always interpreted as absolute imports. (PEP 0328)" ---------- assignee: georg.brandl components: Documentation messages: 76865 nosy: georg.brandl, pwang severity: normal status: open title: Formatting error in "What's New in Python 3.0" versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 04:53:55 2008 From: report at bugs.python.org (Peter Wang) Date: Thu, 04 Dec 2008 03:53:55 +0000 Subject: [issue4516] Another formatting error in "What's New in Python 3.0" In-Reply-To: <1228362835.36.0.473233254769.issue4516@psf.upfronthosting.co.za> Message-ID: <1228362835.36.0.473233254769.issue4516@psf.upfronthosting.co.za> New submission from Peter Wang : In the "Library Changes" section, the next to last bullet point about string.letters has leaked through some ReST markup into the final output: ":data:string.letters`" ---------- assignee: georg.brandl components: Documentation messages: 76866 nosy: georg.brandl, pwang severity: normal status: open title: Another formatting error in "What's New in Python 3.0" versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 05:34:58 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 04 Dec 2008 04:34:58 +0000 Subject: [issue4517] improve __getattribute__ documentation In-Reply-To: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za> Message-ID: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za> New submission from David W. Lambert : http://docs.python.org/dev/3.0/reference/datamodel.html#special-lookup (After fixing the link to http://docs.python.org/3.0 at http://www.python.org/doc/ (and likewise the http://docs.python.org/whatsnew/3.0.html link.)... The comment that __getattribute__ is "Called unconditionally to implement attribute accesses for instances of the class" gave me hope that some combination of "meta" "super" and "sub" might let me access __getattribute__ for expression eval('obj + another_object') despite the special notes. I realize now the truth is that "__getattribute__ is NEVER accessible in pure python code when the code uses the syntax of a unary or binary operator such as a+b, ~a, len(a)." See most of the functions in this manual section. Also name hash, which doesn't find much explicit use but could well be the most used python functionality. Find a smooth way to replace my NEVER since code can obviously access __getattribute__ from the special function. Thank you, and great work! ---------- assignee: georg.brandl components: Documentation messages: 76867 nosy: LambertDW, georg.brandl severity: normal status: open title: improve __getattribute__ documentation type: feature request versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 05:38:59 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 04 Dec 2008 04:38:59 +0000 Subject: [issue4517] improve __getattribute__ documentation In-Reply-To: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za> Message-ID: <1228365539.75.0.145851584059.issue4517@psf.upfronthosting.co.za> David W. Lambert added the comment: >>> class c: ... def __getattribute__(self,*args): ... print('getattribute chimes in') ... >>> c()+3 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'c' and 'int' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 05:48:13 2008 From: report at bugs.python.org (Bernard Gray) Date: Thu, 04 Dec 2008 04:48:13 +0000 Subject: [issue4518] broken link to python 3 doc on main doc page In-Reply-To: <1228366093.31.0.864061220871.issue4518@psf.upfronthosting.co.za> Message-ID: <1228366093.31.0.864061220871.issue4518@psf.upfronthosting.co.za> New submission from Bernard Gray : http://www.python.org/doc/ The "Python 3.0" link in the doc section is broken: Python 3.0 documentation is also available: * What's new in Python 3.0 * Python 3.0 It points to: http://docs.python.org/3.0 which gives a 404 ---------- assignee: georg.brandl components: Documentation messages: 76869 nosy: cleary, georg.brandl severity: normal status: open title: broken link to python 3 doc on main doc page type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:11:52 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 04 Dec 2008 05:11:52 +0000 Subject: [issue4518] broken link to python 3 doc on main doc page In-Reply-To: <1228366093.31.0.864061220871.issue4518@psf.upfronthosting.co.za> Message-ID: <1228367512.21.0.62199855736.issue4518@psf.upfronthosting.co.za> David W. Lambert added the comment: Meanwhile, use http://docs.python.org/dev/3.0/ ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:12:35 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 04 Dec 2008 05:12:35 +0000 Subject: [issue4518] broken link to python 3 doc on main doc page In-Reply-To: <1228366093.31.0.864061220871.issue4518@psf.upfronthosting.co.za> Message-ID: <1228367555.18.0.567008618312.issue4518@psf.upfronthosting.co.za> Changes by David W. Lambert : ---------- nosy: -LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:38:17 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 05:38:17 +0000 Subject: [issue4082] __main__.__file__ not set correctly when -m switch gets __main__ from a zipfile In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za> Message-ID: <1228369097.08.0.00665676432032.issue4082@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:48:00 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 05:48:00 +0000 Subject: [issue4082] __main__.__file__ not set correctly when -m switch gets __main__ from a zipfile In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za> Message-ID: <1228369680.06.0.450614126767.issue4082@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: See issue4512 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:54:53 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2008 05:54:53 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1228370093.94.0.628587250507.issue4197@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: While the patch at issue4512 fixes the crash, it does not fix the line number issue. I would prefer to start with doctest-1.patch like solution because changing the PEP 302 loader protocol by adding get_filename needs additional discussion and certainly is not a candidate for 2.5.x or 2.6.x bug fix releases. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 07:05:19 2008 From: report at bugs.python.org (Leger) Date: Thu, 04 Dec 2008 06:05:19 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228370719.54.0.991391280596.issue4483@psf.upfronthosting.co.za> Leger added the comment: I install the Python3.0 (final), the test make is the same and the result too. I join the output. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 08:12:36 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 04 Dec 2008 07:12:36 +0000 Subject: [issue4514] test_binascii is failing In-Reply-To: <1228360519.8.0.091239531214.issue4514@psf.upfronthosting.co.za> Message-ID: <1228374756.33.0.274993184813.issue4514@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The problem is that the Windows implementation of crc32 is different from the Unix implementation, and that implementation was missed in r67472. The fix should be fairly trivial. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 09:31:18 2008 From: report at bugs.python.org (Matthias Klose) Date: Thu, 04 Dec 2008 08:31:18 +0000 Subject: [issue4519] .pyc files included in 2.6 and 3.0 release tarballs In-Reply-To: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za> Message-ID: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za> New submission from Matthias Klose : Python-2.6/Doc/tools/sphinxext/patchlevel.pyc Python-2.6/Doc/tools/sphinxext/pyspecific.pyc Python-2.6/Doc/tools/roman.pyc same for 3.0 ---------- assignee: barry components: Build messages: 76875 nosy: barry, doko severity: normal status: open title: .pyc files included in 2.6 and 3.0 release tarballs versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 09:37:40 2008 From: report at bugs.python.org (Paul Melis) Date: Thu, 04 Dec 2008 08:37:40 +0000 Subject: [issue4520] Online 3.0 documentation says it's for 3.1a0 In-Reply-To: <1228379860.19.0.911251512364.issue4520@psf.upfronthosting.co.za> Message-ID: <1228379860.19.0.911251512364.issue4520@psf.upfronthosting.co.za> New submission from Paul Melis : On the 3.0 release page (http://python.org/download/releases/3.0/) the link to the online documentation is http://docs.python.org/dev/3.0. However, the doc pages there show the version documented to be "Python v3.1a0". There's even a link called "What's new in Python 3.1?" that doesn't work. Could it be that the pages currently under http://docs.python.org/dev/3.0 should have gone under http://docs.python.org/dev/3.1? ---------- assignee: georg.brandl components: Documentation messages: 76876 nosy: georg.brandl, paulmelis severity: normal status: open title: Online 3.0 documentation says it's for 3.1a0 versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 09:55:45 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Thu, 04 Dec 2008 08:55:45 +0000 Subject: [issue4521] "What's New in Python 3.0" mentions "getcwdu" instead of "getcwdb" In-Reply-To: <1228380945.38.0.905075744468.issue4521@psf.upfronthosting.co.za> Message-ID: <1228380945.38.0.905075744468.issue4521@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : Patch is attached. ---------- assignee: georg.brandl components: Documentation files: whatsnew.patch keywords: patch messages: 76877 nosy: georg.brandl, hagen severity: normal status: open title: "What's New in Python 3.0" mentions "getcwdu" instead of "getcwdb" versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12215/whatsnew.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:44:15 2008 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 04 Dec 2008 10:44:15 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za> Message-ID: <1228387455.08.0.92760643198.issue4201@psf.upfronthosting.co.za> Nick Coghlan added the comment: Issues with the tracker itself go in the meta tracker (see the "Report Tracker Problem" link at the bottom of the left hand navigation menu). It's a separate tracker in order to handle cases where the main tracker is actually down in addition to problems with the functionality. And you're right that the get_filename() limitation is only part of the story rather than all of it (for both this and other issues). I'll still try to look at them all in one go this weekend though. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 12:18:22 2008 From: report at bugs.python.org (Felix Benner) Date: Thu, 04 Dec 2008 11:18:22 +0000 Subject: [issue4522] Module wsgiref is not python3000 ready (unicode issues) In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za> Message-ID: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za> New submission from Felix Benner : wsgiref.handlers.py tries to send strings where bytes is necessary in accordance with PEP333 the attached patch encodes everything with ISO-8859-1. Additionally the patch from Issue 3348 has to be applied. ---------- components: Library (Lib) files: handlers.diff keywords: patch messages: 76879 nosy: tordmor severity: normal status: open title: Module wsgiref is not python3000 ready (unicode issues) versions: Python 3.0 Added file: http://bugs.python.org/file12216/handlers.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 13:25:43 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2008 12:25:43 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228393543.18.0.876505915924.issue4509@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's not a memoryview bug, but a bytearray oddity. The bytearray uses a variable-sized buffer underneath, and it tries to minimize the number of reallocations when changing the object length through some simple heuristics. Therefore, a bytearray has both a logical size (the one which is seen from Python, e.g. len()) and a physical size (which can be greater than the logical size, due to those heuristics). The bug here is that the bytearray only prohibits changing the physical size, not the logical size when there is a buffer pointing to it. This also explains the "\00" you are witnessing at the 5th byte when calling tobytes() on the memoryview object: it is the end-of-string marker which has been inserted when changing the logical size. ---------- nosy: +pitrou priority: -> normal stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:05:59 2008 From: report at bugs.python.org (Matthias Kievernagel) Date: Thu, 04 Dec 2008 13:05:59 +0000 Subject: [issue1581476] Text search gives bad count if called from variable trace Message-ID: <1228395959.99.0.609305732295.issue1581476@psf.upfronthosting.co.za> Matthias Kievernagel added the comment: Nice to see someone working on this. One thing I've checked (iirc): You can set iVar in doSearch by hand like this: iVar.set(2) print 'iVar.get()', iVar.get() And iVar rests at this value. t.search does not change the value. I don't know anything about how the tcl-interpreter is embedded into python. I somehow had the impression there might be a _tkinter limitation there. Something like handling two callbacks into _tkinter at the same time or the tcl interpreter being unresponsive while calling a _tkinter function. At that point I gave up. Seen nothing obvious in _tkinter/Tkinter. Matthias Kievernagel (mkiever/at/web/dot/de) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:09:32 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 04 Dec 2008 13:09:32 +0000 Subject: [issue4519] .pyc files included in 2.6 and 3.0 release tarballs In-Reply-To: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za> Message-ID: <1228396172.62.0.154481226815.issue4519@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I thought we had fixed that :( ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 15:19:02 2008 From: report at bugs.python.org (R. David Murray) Date: Thu, 04 Dec 2008 14:19:02 +0000 Subject: [issue4523] logging module __init__ uses has_key In-Reply-To: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za> Message-ID: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za> New submission from R. David Murray : I ran my ap with -3 and got the following: /usr/lib/python2.6/logging/__init__.py:849: DeprecationWarning: dict.has_key() not supported in 3.x; use the in operator ---------- components: Library (Lib) messages: 76883 nosy: bitdancer severity: normal status: open title: logging module __init__ uses has_key type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 15:20:32 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2008 14:20:32 +0000 Subject: [issue4519] .pyc files included in 2.6 and 3.0 release tarballs In-Reply-To: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za> Message-ID: <1228400432.73.0.693671420536.issue4519@psf.upfronthosting.co.za> STINNER Victor added the comment: Write a clean script (or fix the existing script) and reuse the script for each release ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 15:23:08 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2008 14:23:08 +0000 Subject: [issue4523] logging module __init__ uses has_key In-Reply-To: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za> Message-ID: <1228400588.87.0.894151491786.issue4523@psf.upfronthosting.co.za> STINNER Victor added the comment: The regression tests are already running with -bb. We should also use -3 to detect such bug. But is "-3" enough to raise an error (and not just display a message)? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:01:41 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2008 15:01:41 +0000 Subject: [issue4523] logging module __init__ uses has_key In-Reply-To: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za> Message-ID: <1228402901.83.0.312425334434.issue4523@psf.upfronthosting.co.za> STINNER Victor added the comment: I tried the whole Python test suite with -3. Some warnings: - no more cPikle and bsddb modules - has_key() (used in many tests) - a <> b (used in many AST/grammar tests) - an exception have to inherit from Exception - callable() doesn't exist anymore - etc. It's not a good idea to fix the regression tests because Python 2.6 still uses the listed features. But the logging warning should be fixed, so here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file12217/logging_py3k.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:17:03 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 04 Dec 2008 15:17:03 +0000 Subject: [issue2102] New style vs. old style classes __ror__() operator overloading In-Reply-To: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za> Message-ID: <1228403823.6.0.221369964466.issue2102@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : ---------- assignee: fdrake -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:19:08 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 04 Dec 2008 15:19:08 +0000 Subject: [issue1163367] correct/clarify documentation for super Message-ID: <1228403948.04.0.9147786466.issue1163367@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Clearly, I've not gotten to this; unassigning from myself. Probably a good thing, since I'm one of the people who probably don't use it correctly in all cases. ---------- assignee: fdrake -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:34:35 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 04 Dec 2008 15:34:35 +0000 Subject: [issue1019882] hotshot start / stop stats bug Message-ID: <1228404875.31.0.0475324469836.issue1019882@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : ---------- assignee: fdrake -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:37:11 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 04 Dec 2008 15:37:11 +0000 Subject: [issue873150] pickletools support for multiple pickles in a string Message-ID: <1228405031.27.0.45900642956.issue873150@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: I can't remember why I wanted this; guess this should indeed go in the pickleeverydamnfoolfunctionicanthinkof module, not the standard library. ---------- resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:42:22 2008 From: report at bugs.python.org (Chris Hills) Date: Thu, 04 Dec 2008 15:42:22 +0000 Subject: [issue4524] Build fails at running build_scripts In-Reply-To: <1228405342.46.0.981738131113.issue4524@psf.upfronthosting.co.za> Message-ID: <1228405342.46.0.981738131113.issue4524@psf.upfronthosting.co.za> New submission from Chris Hills : On linux-g++-32 with command line `./configure --enable-ipv6 --with- suffix=3`, python is compiled okay but the build scripts fail as follows:- running build_scripts copying and adjusting /tmp/Python-3.0/Tools/scripts/idle -> build/ scripts-3.0 Traceback (most recent call last): File "./setup.py", line 1533, in main() File "./setup.py", line 1528, in main 'Lib/smtpd.py'] File "/tmp/Python-3.0/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-3.0/Lib/distutils/dist.py", line 942, in run_commands self.run_command(cmd) File "/tmp/Python-3.0/Lib/distutils/dist.py", line 962, in run_command cmd_obj.run() File "/tmp/Python-3.0/Lib/distutils/command/build.py", line 128, in run self.run_command(cmd_name) File "/tmp/Python-3.0/Lib/distutils/cmd.py", line 317, in run_command self.distribution.run_command(command) File "/tmp/Python-3.0/Lib/distutils/dist.py", line 962, in run_command cmd_obj.run() File "/tmp/Python-3.0/Lib/distutils/command/build_scripts.py", line 51, in run self.copy_scripts() File "/tmp/Python-3.0/Lib/distutils/command/build_scripts.py", line 108, in copy_scripts + sysconfig.get_config_var("EXE")), TypeError: Can't convert 'int' object to str implicitly make: *** [sharedmods] Error 1 ---------- components: Build messages: 76889 nosy: chaz6 severity: normal status: open title: Build fails at running build_scripts type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:49:42 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 04 Dec 2008 15:49:42 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <1228339825.17.0.783504500876.issue4506@psf.upfronthosting.co.za> Message-ID: <18743.64529.80385.143932@montanaro-dyndns-org.local> Skip Montanaro added the comment: Mark> If you have time, could you try the attached patch and report what Mark> gets printed when cmath.exp(710+1.5j) is called? On my machine, I Mark> get: ... Looks similar here: % ./python Python 3.0 (r30:67503, Dec 3 2008, 14:46:39) [GCC 4.2.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cmath >>> cmath.exp(complex(710.0, 1.5)) r.real, r.imag: 1.58027e+307, Inf Py_IS_INFINITY(r.real), Py_IS_INFINITY(r.imag): 0, 1 Traceback (most recent call last): File "", line 1, in OverflowError: math range error If I then comment back out your two printf statements and recompile, it once again fails to raise OverflowError: % ./python Python 3.0 (r30:67503, Dec 3 2008, 14:46:39) [GCC 4.2.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cmath ; cmath.exp(complex(710.0, 1.5)) (1.5802653829857376e+307+inf*j) Very weird. If I uncomment either of your printf statements OverflowError seems to be raised as expected. It's as if some register bit isn't being set unless you reference r.real or r.imag multiple times. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 17:15:39 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 04 Dec 2008 16:15:39 +0000 Subject: [issue4524] Build fails at running build_scripts In-Reply-To: <1228405342.46.0.981738131113.issue4524@psf.upfronthosting.co.za> Message-ID: <1228407339.33.0.724610679405.issue4524@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The cause is that distutils.sysconfig.parse_makefile() tries to convert each value to an int, and does succeed on "--with-suffix=3". The attached patch uses %s formatting to build the program name, this will accept int values. All versions are affected. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc stage: -> patch review versions: +Python 2.6 Added file: http://bugs.python.org/file12218/build_scripts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 17:23:13 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 04 Dec 2008 16:23:13 +0000 Subject: [issue672132] registry functions don't handle null characters Message-ID: <1228407793.13.0.154631428268.issue672132@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: """I expect one day people will complain that they can't access certain registry keys, because those use characters not supported in CP_ACP. """ These people should migrate to python 3.0. ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 17:37:27 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 04 Dec 2008 16:37:27 +0000 Subject: [issue4525] metaclass fixer fails with AttributeError, causing 2to3 to exit with a traceback In-Reply-To: <1228408647.08.0.619870488984.issue4525@psf.upfronthosting.co.za> Message-ID: <1228408647.08.0.619870488984.issue4525@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone : I tried running 2to3 on Twisted. Here's the result: exarkun at charm:~/Projects/Twisted/trunk$ time ~/Projects/python/branches/release26-maint/python /home/exarkun/Projects/python/branches/release26-maint/Tools/scripts/2to3 twisted/ > 2to3.patch /home/exarkun/Projects/Divmod/trunk/Combinator/combinator/xsite.py:7: DeprecationWarning: the sets module is deprecated from sets import Set RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: ws_comma Traceback (most recent call last): File "/home/exarkun/Projects/python/branches/release26-maint/Tools/scripts/2to3", line 6, in sys.exit(main("lib2to3.fixes")) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/main.py", line 92, in main rt.refactor(args, options.write, options.doctests_only) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py", line 196, in refactor self.refactor_dir(dir_or_file, write, doctests_only) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py", line 214, in refactor_dir self.refactor_file(fullname, write, doctests_only) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py", line 237, in refactor_file tree = self.refactor_string(input, filename) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py", line 262, in refactor_string self.refactor_tree(tree, name) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py", line 301, in refactor_tree self.traverse_by(self.post_order, tree.post_order()) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py", line 325, in traverse_by new = fixer.transform(node, results) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/fixes/fix_metaclass.py", line 148, in transform if not has_metaclass(node): File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/fixes/fix_metaclass.py", line 34, in has_metaclass return has_metaclass(node) File "/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/fixes/fix_metaclass.py", line 39, in has_metaclass if leaf_node.value == '__metaclass__': AttributeError: 'Node' object has no attribute 'value' real 0m32.451s user 0m31.498s sys 0m0.140s exarkun at charm:~/Projects/Twisted/trunk$ There's no indication of what it was processing, so I'm not sure what causes the error. ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 76893 nosy: exarkun severity: normal status: open title: metaclass fixer fails with AttributeError, causing 2to3 to exit with a traceback type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 17:38:42 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 04 Dec 2008 16:38:42 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228408722.07.0.926118698126.issue4506@psf.upfronthosting.co.za> Skip Montanaro added the comment: Mark, I trimmed down cmathmodule.c to just contain c_exp then generated assembler files for the non-printf and printf cases. Perhaps that will help you see what's going on. Skip Added file: http://bugs.python.org/file12219/cmathmodule.S _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 17:39:02 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 04 Dec 2008 16:39:02 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228408742.63.0.543762240677.issue4506@psf.upfronthosting.co.za> Changes by Skip Montanaro : Added file: http://bugs.python.org/file12220/cmathmodule.S.printf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 17:43:30 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 04 Dec 2008 16:43:30 +0000 Subject: [issue783789] SIGSEGV in _sre.c (IRIX 6.5.20) Message-ID: <1228409010.63.0.0566851817478.issue783789@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This looks like a stack overflow to me, and the re module is no longer recursive since python2.4. ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:06:22 2008 From: report at bugs.python.org (Akira Kitada) Date: Thu, 04 Dec 2008 17:06:22 +0000 Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11 In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za> Message-ID: <1228410382.37.0.221675412071.issue4368@psf.upfronthosting.co.za> Akira Kitada added the comment: I think this patch is harmless and also deserve to be merged into 2.5.3 release. (As I mentioned earlier, this has been already merged into 3.0 and 2.6 branches) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:11:00 2008 From: report at bugs.python.org (Bobby Xiao) Date: Thu, 04 Dec 2008 17:11:00 +0000 Subject: [issue4526] Clarify documentation for binary literals In-Reply-To: <1228410660.54.0.04867017441.issue4526@psf.upfronthosting.co.za> Message-ID: <1228410660.54.0.04867017441.issue4526@psf.upfronthosting.co.za> New submission from Bobby Xiao : Under http://docs.python.org/dev/3.0/whatsnew/3.0.html#new-syntax, on the last two points, it says "# New binary literals, e.g. 0b1010 (already in 2.6). # Bytes literals are introduced with a leading b or B, and there is a new corresponding builtin function, bin()." I believe it should read "# New binary literals, e.g. 0b1010 (already in 2.6), and there is a new corresponding builtin function, bin(). # Bytes literals are introduced with a leading b or B, and there is a new corresponding builtin function, bytes()." or something along those lines, as "bin" is for binary literals, not bytes literals, and "bytes" is for bytes literals. ---------- assignee: georg.brandl components: Documentation messages: 76897 nosy: georg.brandl, nneonneo severity: normal status: open title: Clarify documentation for binary literals versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:13:29 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Dec 2008 17:13:29 +0000 Subject: [issue4527] Obsolete 'string or unicode' in fractions doc In-Reply-To: <1228410809.2.0.0869447431256.issue4527@psf.upfronthosting.co.za> Message-ID: <1228410809.2.0.0869447431256.issue4527@psf.upfronthosting.co.za> New submission from Terry J. Reedy : "The last version of the constructor expects a string or unicode instance in one of two possible forms. " Delete 'or unicode' (bytes do not work). Doc string is ok. ---------- assignee: georg.brandl components: Documentation keywords: easy messages: 76898 nosy: georg.brandl, tjreedy severity: normal status: open title: Obsolete 'string or unicode' in fractions doc versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:17:37 2008 From: report at bugs.python.org (Martin Diers) Date: Thu, 04 Dec 2008 17:17:37 +0000 Subject: [issue4528] test_httpservers consistently fails on OS X In-Reply-To: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za> Message-ID: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za> New submission from Martin Diers : Test was run with sudo. All other tests passed. Here is the verbose output of test_httpservers: Re-running test 'test_httpservers' in verbose mode test_command (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_handler (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_head_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_header_close (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_internal_key_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_request_line_trimming (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_return_custom_status (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_return_header_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_send_blank (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_version_bogus (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_version_digits (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_version_invalid (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_version_none (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_version_none_get (test.test_httpservers.BaseHTTPServerTestCase) ... ok test_get (test.test_httpservers.SimpleHTTPServerTestCase) ... FAIL test_head (test.test_httpservers.SimpleHTTPServerTestCase) ... ok test_invalid_requests (test.test_httpservers.SimpleHTTPServerTestCase) ... ok test_authorization (test.test_httpservers.CGIHTTPServerTestCase) ... Traceback (most recent call last): File "/Users/mwdiers/src/Python-3.0/Lib/http/server.py", line 1031, in run_cgi os.execve(scriptfile, args, os.environ) OSError: [Errno 13] Permission denied ERROR test_headers_and_content (test.test_httpservers.CGIHTTPServerTestCase) ... Traceback (most recent call last): File "/Users/mwdiers/src/Python-3.0/Lib/http/server.py", line 1031, in run_cgi os.execve(scriptfile, args, os.environ) OSError: [Errno 13] Permission denied ERROR test_invaliduri (test.test_httpservers.CGIHTTPServerTestCase) ... ok test_post (test.test_httpservers.CGIHTTPServerTestCase) ... Traceback (most recent call last): File "/Users/mwdiers/src/Python-3.0/Lib/http/server.py", line 1031, in run_cgi os.execve(scriptfile, args, os.environ) OSError: [Errno 13] Permission denied FAIL ====================================================================== ERROR: test_authorization (test.test_httpservers.CGIHTTPServerTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py", line 342, in test_authorization (res.read(), res.getheader('Content-type'), res.status)) File "/Users/mwdiers/src/Python-3.0/Lib/http/client.py", line 591, in getheader return ', '.join(self.msg.get_all(name, default)) TypeError ====================================================================== ERROR: test_headers_and_content (test.test_httpservers.CGIHTTPServerTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py", line 322, in test_headers_and_content (res.read(), res.getheader('Content-type'), res.status)) File "/Users/mwdiers/src/Python-3.0/Lib/http/client.py", line 591, in getheader return ', '.join(self.msg.get_all(name, default)) TypeError ====================================================================== FAIL: test_get (test.test_httpservers.SimpleHTTPServerTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py", line 244, in test_get self.check_status_and_reason(response, 404) File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py", line 220, in check_status_and_reason self.assertEquals(response.status, status) AssertionError: 200 != 404 ====================================================================== FAIL: test_post (test.test_httpservers.CGIHTTPServerTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py", line 330, in test_post self.assertEquals(res.read(), b'1, python, 123456\n') AssertionError: b'' != b'1, python, 123456\n' ---------------------------------------------------------------------- Ran 21 tests in 10.358s FAILED (failures=2, errors=2) test test_httpservers failed -- errors occurred; run in verbose mode for details make: [test] Error 1 (ignored) ---------- components: Tests messages: 76899 nosy: mwdiers severity: normal status: open title: test_httpservers consistently fails on OS X type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:22:10 2008 From: report at bugs.python.org (Kai Willadsen) Date: Thu, 04 Dec 2008 17:22:10 +0000 Subject: [issue4529] parser module failure on valid try/except/finally blocks In-Reply-To: <1228411329.74.0.280169454791.issue4529@psf.upfronthosting.co.za> Message-ID: <1228411329.74.0.280169454791.issue4529@psf.upfronthosting.co.za> New submission from Kai Willadsen : Using the parser module to create a parse tree succeeds, but a subsequent tuple2ast fails, when parsing valid try/except/finally (and try/except/else/finally) blocks. parser.tuple2ast fails with: parser.ParserError: Illegal number of children for try/finally node. ---------- files: parser-testcase.py messages: 76900 nosy: kaiw severity: normal status: open title: parser module failure on valid try/except/finally blocks type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file12221/parser-testcase.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:24:21 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 04 Dec 2008 17:24:21 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za> Message-ID: <1228411461.69.0.457608256197.issue4342@psf.upfronthosting.co.za> Changes by Guilherme Polo : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:30:49 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 04 Dec 2008 17:30:49 +0000 Subject: [issue818059] os.listdir on empty strings. Inconsistent behaviour. Message-ID: <1228411849.6.0.507624182346.issue818059@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This may become important when switching to python 3.0... When passed str(''), FindFirstFileA is called with "*.*". But when passed unicode(''), FindFirstFileW is called with L"\\*.*" !!! Attached patch fixes (and tests) the problem. It was developed on 3.0, but applies on all versions. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc priority: normal -> high stage: -> patch review Added file: http://bugs.python.org/file12222/listdir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:39:22 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 04 Dec 2008 17:39:22 +0000 Subject: [issue4525] metaclass fixer fails with AttributeError, causing 2to3 to exit with a traceback In-Reply-To: <1228408647.08.0.619870488984.issue4525@psf.upfronthosting.co.za> Message-ID: <1228412362.67.0.0856879397794.issue4525@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes, the 2.6.0 version of 2to3 is broken in this way. 2.6.1 should be released today or tomorrow. In the mean time, you can try it directly from the 2to3 trunk: http://svn.python.org/projects/sandbox/trunk/2to3 ---------- nosy: +benjamin.peterson resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:44:08 2008 From: report at bugs.python.org (Paul Goins) Date: Thu, 04 Dec 2008 17:44:08 +0000 Subject: [issue4530] IDLE crashes with Japanese text on print command In-Reply-To: <1228412648.37.0.825902447476.issue4530@psf.upfronthosting.co.za> Message-ID: <1228412648.37.0.825902447476.issue4530@psf.upfronthosting.co.za> New submission from Paul Goins : Just got Python 3.0 final on Windows and was testing out IDLE, and it's having some issues. Specifically: * Options -> Configure IDLE..., General Tab: Change Default Source Encoding from None to UTF-8 * Create a new python file and enter a print command containing Japanese text. Save it. (Saves to UTF-8.) * Press F5 to run the script. IDLE crashes. However, if the default encoding is left as "None", and you create a new file and allow IDLE to save it as cp932, then it runs with no problem through IDLE. Straight Python on a command line is not affected and reads the UTF-8 files perfectly fine. Attached is a script which crashes IDLE every single time I run it. Thanks. - Paul Goins ---------- components: IDLE files: test.py messages: 76903 nosy: Vultaire severity: normal status: open title: IDLE crashes with Japanese text on print command versions: Python 3.0 Added file: http://bugs.python.org/file12223/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:51:23 2008 From: report at bugs.python.org (Edward K Ream) Date: Thu, 04 Dec 2008 17:51:23 +0000 Subject: [issue4531] Deprecation warnings in lib\compiler\ast.py In-Reply-To: <1228413082.92.0.670924169778.issue4531@psf.upfronthosting.co.za> Message-ID: <1228413082.92.0.670924169778.issue4531@psf.upfronthosting.co.za> New submission from Edward K Ream : Python 2.6 final on Windows XP gives following warnings with -3 option: c:\python26\lib\compiler\ast.py:54: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:434: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:488: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:806: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:896: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:926: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:998: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:1098: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\ast.py:1173: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def __init__(self, (left, right), lineno=None): c:\python26\lib\compiler\pycodegen.py:903: SyntaxWarning: tuple parameter unpacking has been removed in 3.x Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo at gmail.com Leo: http://webpages.charter.net/edreamleo/front.html -------------------------------------------------------------------- ---------- components: Library (Lib) messages: 76904 nosy: edreamleo severity: normal status: open title: Deprecation warnings in lib\compiler\ast.py type: compile error versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:19:56 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:19:56 +0000 Subject: [issue4527] Obsolete 'string or unicode' in fractions doc In-Reply-To: <1228410809.2.0.0869447431256.issue4527@psf.upfronthosting.co.za> Message-ID: <1228414796.92.0.852873183042.issue4527@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67525. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:20:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:20:04 +0000 Subject: [issue4526] Clarify documentation for binary literals In-Reply-To: <1228410660.54.0.04867017441.issue4526@psf.upfronthosting.co.za> Message-ID: <1228414804.95.0.114974427443.issue4526@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67526. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:21:27 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 04 Dec 2008 18:21:27 +0000 Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za> Message-ID: <1228414887.83.0.444432825755.issue3890@psf.upfronthosting.co.za> Bill Janssen added the comment: Thanks for the patch. It looks pretty good to me, but I can't help thinking that there must be a better way of handling the recv() case; I don't like copying that buffer several times (from the SSL code to Python, from the Python to the buffer). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:21:59 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:21:59 +0000 Subject: [issue4521] "What's New in Python 3.0" mentions "getcwdu" instead of "getcwdb" In-Reply-To: <1228380945.38.0.905075744468.issue4521@psf.upfronthosting.co.za> Message-ID: <1228414919.85.0.939826993944.issue4521@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, applied as r67527. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:22:57 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:22:57 +0000 Subject: [issue4520] Online 3.0 documentation says it's for 3.1a0 In-Reply-To: <1228379860.19.0.911251512364.issue4520@psf.upfronthosting.co.za> Message-ID: <1228414977.48.0.737244960458.issue4520@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, this was a temporary workaround for another issue. 3.0 and 3.1 docs are now properly separated and linked to. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:24:03 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:24:03 +0000 Subject: [issue4518] broken link to python 3 doc on main doc page In-Reply-To: <1228366093.31.0.864061220871.issue4518@psf.upfronthosting.co.za> Message-ID: <1228415043.58.0.248935910317.issue4518@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed now, thanks. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:25:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:25:02 +0000 Subject: [issue4516] Another formatting error in "What's New in Python 3.0" In-Reply-To: <1228362835.36.0.473233254769.issue4516@psf.upfronthosting.co.za> Message-ID: <1228415102.93.0.853177686258.issue4516@psf.upfronthosting.co.za> Georg Brandl added the comment: This appears to be fixed in SVN. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:25:14 2008 From: report at bugs.python.org (Matt Kraai) Date: Thu, 04 Dec 2008 18:25:14 +0000 Subject: [issue4532] Fails to build on QNX 6.3.2 In-Reply-To: <1228415114.24.0.8798028778.issue4532@psf.upfronthosting.co.za> Message-ID: <1228415114.24.0.8798028778.issue4532@psf.upfronthosting.co.za> New submission from Matt Kraai : When I try to build Python 3.0 on QNX 6.3.2, the build has the following error: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/pythonrun.o Python/pythonrun.c Python/pythonrun.c: In function `Py_InitializeEx': ... Python/pythonrun.c:180: `LC_CTYPE' undeclared (first use in this function) Python/pythonrun.c:180: (Each undeclared identifier is reported only once Python/pythonrun.c:180: for each function it appears in.) ... make: *** [Python/pythonrun.o] Error 1 LC_CTYPE is defined in locale.h, which isn't included because HAVE_LANGINFO_H isn't defined because QNX 6.3.2 doesn't provide langinfo.h. The setlocale call in the trunk is guarded by HAVE_LANGINFO_H, so maybe that should be done here as well. Once this error has been fixed, the following error occurs: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -DPYTHONPATH='":plat-qnx6"' \ -DPREFIX='"/usr/local"' \ -DEXEC_PREFIX='"/usr/local"' \ -DVERSION='"3.0"' \ -DVPATH='""' \ -o Modules/getpath.o ./Modules/getpath.c ./Modules/getpath.c:132: invalid initializer ... make: *** [Modules/getpath.o] Error 1 This version of GCC apparently cannot handle wchar_t array initializers. This can be worked around by changing the type of lib_python to a wchar_t pointer instead. ---------- components: Build files: fix-qnx-build-errors messages: 76912 nosy: kraai severity: normal status: open title: Fails to build on QNX 6.3.2 type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file12224/fix-qnx-build-errors _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:26:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:26:17 +0000 Subject: [issue4515] Formatting error in "What's New in Python 3.0" In-Reply-To: <1228362415.59.0.446802801045.issue4515@psf.upfronthosting.co.za> Message-ID: <1228415177.0.0.9442631615.issue4515@psf.upfronthosting.co.za> Georg Brandl added the comment: This appears to be fixed in SVN. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:28:47 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Dec 2008 18:28:47 +0000 Subject: [issue4513] Finish updating zip docstring In-Reply-To: <1228355563.66.0.943103489594.issue4513@psf.upfronthosting.co.za> Message-ID: <1228415327.58.0.217097099653.issue4513@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67529. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:30:20 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Dec 2008 18:30:20 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> New submission from Terry J. Reedy : C.l.p poster reported that 3.0 file.read is orders of magnitude slower than with 2.5 (but confused issue with buffer = 0). Jerry Hill reported "Here's a quick comparison between 2.5 and 3.0 on a relatively small 17 meg file: C:\>c:\Python30\python -m timeit -n 1 "open('C:\\work\\temp\\bppd_vsub.csv', 'rb').read()" 1 loops, best of 3: 36.8 sec per loop C:\>c:\Python25\python -m timeit -n 1 "open('C:\\work\\temp\\bppd_vsub.csv', 'rb').read()" 1 loops, best of 3: 33 msec per loop That's 3 orders of magnitude slower on python3.0!" I verified this informally on WinXP by opening and then reading Doc/Pythonxy.chm (about 4 megs) -- an eye blink versus 3 seconds, repeated. Even the open seemed slower but I did not time it. >>> f=open('Doc/Python30.chm','rb') >>> d=f.read() ---------- components: Interpreter Core, Library (Lib) messages: 76915 nosy: tjreedy severity: normal status: open title: 3.0 file.read dreadfully slow type: performance versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:33:01 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 04 Dec 2008 18:33:01 +0000 Subject: [issue4531] Deprecation warnings in lib\compiler\ast.py In-Reply-To: <1228413082.92.0.670924169778.issue4531@psf.upfronthosting.co.za> Message-ID: <1228415581.33.0.371079082641.issue4531@psf.upfronthosting.co.za> Brett Cannon added the comment: Considering the entire compiler package is not in 3.0 it is not worth fixing this. Closing as wont fix. ---------- nosy: +brett.cannon resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 20:17:29 2008 From: report at bugs.python.org (Edward K Ream) Date: Thu, 04 Dec 2008 19:17:29 +0000 Subject: [issue4531] Deprecation warnings in lib\compiler\ast.py In-Reply-To: <1228415581.33.0.371079082641.issue4531@psf.upfronthosting.co.za> Message-ID: Edward K Ream added the comment: On Thu, Dec 4, 2008 at 12:33 PM, Brett Cannon wrote: > > Brett Cannon added the comment: > > Considering the entire compiler package is not in 3.0 it is not worth > fixing this. Closing as wont fix. Thanks for this clarification. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo at gmail.com Leo: http://webpages.charter.net/edreamleo/front.html -------------------------------------------------------------------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 20:17:30 2008 From: report at bugs.python.org (darrenr) Date: Thu, 04 Dec 2008 19:17:30 +0000 Subject: [issue4273] cycle created by profile.run In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> Message-ID: <1228418250.58.0.310463473835.issue4273@psf.upfronthosting.co.za> darrenr added the comment: We've gotten into the habit of writing manual destructors to remove references like the one you wrote. I think explicit destruction is a useful paradigm when resource allocation is involved and it's important to manage the allocation's lifetime closely. However you've convinced me that it's OK to allow these types of reference cycles, and to make an effort to clean up only cycles involving instances with __del__ methods. I've been able to convince the team. Thanks for helping to clear this up. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 20:20:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 04 Dec 2008 19:20:13 +0000 Subject: [issue1163367] correct/clarify documentation for super Message-ID: <1228418413.23.0.379412415946.issue1163367@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll look at this further. Since it was originally posted, there have already been several improvements to the super() docs. FWIW, there will be no links to super-considered-harmful. Guido has frowned upon that document. Our documentation needs to be written in an affirmative manner, indicating what problems super() solves and how to use it well. This is far better than itemizing its misuses and suggesting that it is an anti-feature. ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:21:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 04 Dec 2008 20:21:31 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228422091.52.0.971241237475.issue4533@psf.upfronthosting.co.za> Christian Heimes added the comment: This needs definitely some testing! ---------- components: +Extension Modules nosy: +christian.heimes priority: -> release blocker stage: -> test needed versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:21:39 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 04 Dec 2008 20:21:39 +0000 Subject: [issue1055234] cgi.py does not correctly handle fields with ';' Message-ID: <1228422099.45.0.798038992602.issue1055234@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: This is now fixed for Python 2.6.?, 2.7, 3.0.1, and 3.1. I've no idea why I didn't write a test for this sooner. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:23:23 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 04 Dec 2008 20:23:23 +0000 Subject: [issue4519] .pyc files included in 2.6 and 3.0 release tarballs In-Reply-To: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za> Message-ID: <1228422203.88.0.202410506415.issue4519@psf.upfronthosting.co.za> Christian Heimes added the comment: Ups ... I didn't noticed it, too. ---------- nosy: +christian.heimes stage: -> needs patch type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:24:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 04 Dec 2008 20:24:35 +0000 Subject: [issue4522] Module wsgiref is not python3000 ready (unicode issues) In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za> Message-ID: <1228422275.95.0.75631677084.issue4522@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- priority: -> critical stage: -> patch review type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:28:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 04 Dec 2008 20:28:47 +0000 Subject: [issue4532] Fails to build on QNX 6.3.2 In-Reply-To: <1228415114.24.0.8798028778.issue4532@psf.upfronthosting.co.za> Message-ID: <1228422527.33.0.453399027692.issue4532@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch is looking good to me. ---------- nosy: +christian.heimes priority: -> release blocker stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:34:22 2008 From: report at bugs.python.org (jeff deifik) Date: Thu, 04 Dec 2008 20:34:22 +0000 Subject: [issue4534] problem with str.join In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> New submission from jeff deifik : I compiled python 3.0 on a cygwin platform. Here is my modest function: def List_to_String(lis): # return str.join(lis, '') # This is fast, but seems broke in 3.0 s = '' # This is really slow, but works in 3.0 for l in lis: s = s + l return s Here is my test case: def test_List_to_String(self): inp = ['f', 'r', 'e', 'd', ' ', 'i', 's'] out = 'fred is' self.assertEqual(jefflib.List_to_String(inp), out) Here is what happens when I try to run the commented out version (the one with the join): ERROR: test_List_to_String (__main__.TestJefflibFunctions) ---------------------------------------------------------------------- Traceback (most recent call last): File "./jefflib_test.py", line 96, in test_List_to_String self.assertEqual(jefflib.List_to_String(inp), out) File "/cygdrive/c/documents and settings/deifikj/jeff/scripts/jefflib.py", lin e 256, in List_to_String return str.join(lis) TypeError: descriptor 'join' requires a 'str' object but received a 'list' Of course, it worked fine in python 2.6. I am baffled. ---------- components: None messages: 76924 nosy: lopgok severity: normal status: open title: problem with str.join type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:35:03 2008 From: report at bugs.python.org (Rob Wiers) Date: Thu, 04 Dec 2008 20:35:03 +0000 Subject: [issue4535] Build / Test Py3K failed on Ubuntu 8.10 Message-ID: <1228422903.09.0.836459450544.issue4535@psf.upfronthosting.co.za> Changes by Rob Wiers : ---------- components: Build files: py3k.out nosy: lbhudda severity: normal status: open title: Build / Test Py3K failed on Ubuntu 8.10 type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file12225/py3k.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:35:14 2008 From: report at bugs.python.org (jeff deifik) Date: Thu, 04 Dec 2008 20:35:14 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228422914.13.0.660968926707.issue4534@psf.upfronthosting.co.za> Changes by jeff deifik : ---------- title: problem with str.join -> problem with str.join - should work with list input, error says requires 'str' object _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:37:26 2008 From: report at bugs.python.org (Rob Wiers) Date: Thu, 04 Dec 2008 20:37:26 +0000 Subject: [issue4535] Build / Test Py3K failed on Ubuntu 8.10 In-Reply-To: <1228423046.58.0.110673745829.issue4535@psf.upfronthosting.co.za> Message-ID: <1228423046.58.0.110673745829.issue4535@psf.upfronthosting.co.za> New submission from Rob Wiers : After reading about the Py3K release, I downloaded the source distribution and did a build and test. The test failed, and I thought it might be useful to share it here. I realise there is probably a person (or group) dedicated to porting Python 3.0 to Ubuntu, but I thought this might be helpful. If not, please let me know. Regards, Rob Wiers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:50:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 04 Dec 2008 20:50:19 +0000 Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za> Message-ID: <1228423819.91.0.739278404548.issue2486@psf.upfronthosting.co.za> Mark Dickinson added the comment: Just a quick note to say I am still working on this. I'll post some new code soon. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:54:41 2008 From: report at bugs.python.org (Chris Hills) Date: Thu, 04 Dec 2008 20:54:41 +0000 Subject: [issue4524] Build fails at running build_scripts In-Reply-To: <1228405342.46.0.981738131113.issue4524@psf.upfronthosting.co.za> Message-ID: <1228424081.56.0.893059851545.issue4524@psf.upfronthosting.co.za> Chris Hills added the comment: In hindsight I did not need to use --with-suffix as I assumed the interpreter would be installed as "python" by default, but it is not. The patch however does fix the reported problem for me. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:55:04 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 04 Dec 2008 20:55:04 +0000 Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8 values In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za> Message-ID: <1228424104.13.0.0853658855254.issue4006@psf.upfronthosting.co.za> Changes by Adam Olsen : ---------- nosy: +Rhamphoryncus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:20:37 2008 From: report at bugs.python.org (Laszlo) Date: Thu, 04 Dec 2008 21:20:37 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> New submission from Laszlo : >>> range(1.0, 0, 1) Traceback (most recent call last): File "", line 1, in TypeError: 'float' object cannot be interpreted as an integer >>> range(1.0, 0, -1) Traceback (most recent call last): File "", line 1, in SystemError: NULL result without error in PyObject_Call The error here is that range() does not accept float arguments. However in the second example the step argument is -1. Since -1 is also used to indicate a integer overflow, when processing the step argument, it is assumed that (step == -1 && PyErr_Occurred()) means that an overflow occured. However in this particular case, step is supposed to be -1, and the error is a TypeError from the previous argument which is a float. The error is then cleared and step is rounded to fit inside an integer. start = PyNumber_Index(start); stop = PyNumber_Index(stop); step = validate_step(step); if (!start || !stop || !step) goto Fail; Now in the above code start is NULL, and the if statement checks for this, and goes to Fail which return NULL. But no error condition is set (it was cleared before) and NULL raises a SystemError. My patch changes three things: * In validate_step(): remove unnecessary 'step = PyNumber_Index(step)', because this PyNumber_Index conversion is already done in the next line by PyNumber_AsSsize_t(). * In validate_step(): don't clear the error is the result is -1. The overflow error is already cleared by PyNumber_AsSsize_t(), and any other errors should remain. * In range_new(): check for NULL values before calling validate_step(), because unlike for the other arguments where we call PyNumber_Index(), calling validate_step() may clear the previous error. ---------- components: Interpreter Core files: range.diff keywords: patch messages: 76928 nosy: laszlo severity: normal status: open title: SystemError if invalid arguments passed to range() and step=-1 type: behavior versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12226/range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:23:23 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 04 Dec 2008 21:23:23 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228425803.9.0.485448222858.issue4506@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the assembly code---you're running Solaris on x86! Why didn't you say so before? :) I think I have an idea what's going on: it's the old extended-precision versus double-precision problem. The calculation of c_exp is done in extended precision in the 80-bit registers of the x87 FPU. The imaginary part of the result of c_exp(710+1.5j) is representable in extended precision, but is outside the range of double precision. So at the point of the Py_IS_INFINITY call, the comparison is done in the FPU and the value being tested isn't infinity. But sometime after that this value is forced out of the 80-bit extended precision FPU register and into memory, where it becomes a 64-bit IEEE 754 double precision infinity. I guess the printf calls force the value from register to memory earlier, so that by the time of the Py_IS_INFINITY call it's already a 64-bit double, and hence already an infinity. Now to prove my theory by turning this into a fix, somehow. It seems as though this problem isn't really specific to Solaris; I guess it's just luck that it hasn't shown up on other x86 platforms. It should certainly be fixed. For the test_math failure, there have been problems with log on other platforms, too, mostly due to strange libm behaviour. The obvious solution is to adapt the Python implementation to deal with special values itself, rather than leaving them to the platform math library. Should be a fairly straightforward change. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:48:47 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 04 Dec 2008 21:48:47 +0000 Subject: [issue4273] cycle created by profile.run In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> Message-ID: <1228427327.73.0.804453799181.issue4273@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Closing issue as "Not a bug". (but we can continue the discussion here...) ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:49:10 2008 From: report at bugs.python.org (Michael Schurter) Date: Thu, 04 Dec 2008 21:49:10 +0000 Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> Message-ID: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> New submission from Michael Schurter : On the joyous occasion of Python 3000's release my friends & I were playing with "import antigravity" and it failed for someone with the following traceback (anonymized): Traceback (most recent call last): File "", line 1, in File "/.../lib/python3.0/antigravity.py", line 4, in webbrowser.open("http://xkcd.com/353/") File "/.../lib/python3.0/webbrowser.py", line 61, in open if browser.open(url, new, autoraise): File "/.../lib/python3.0/webbrowser.py", line 275, in open success = self._invoke(args, True, autoraise) File "/.../lib/python3.0/webbrowser.py", line 226, in _invoke inout = open(os.devnull, "r+") File "/.../lib/python3.0/webbrowser.py", line 61, in open if browser.open(url, new, autoraise): File "/.../lib/python3.0/webbrowser.py", line 271, in open "expected 0, 1, or 2, got %s" % new) webbrowser.Error: Bad 'new' parameter to open(); expected 0, 1, or 2, got r+ I believe the following patch (against branches/release30-maint) fixes it cleanly: Index: Lib/webbrowser.py =================================================================== --- Lib/webbrowser.py (revision 67538) +++ Lib/webbrowser.py (working copy) @@ -8,6 +8,7 @@ import stat import subprocess import time +import builtins __all__ = ["Error", "open", "open_new", "open_new_tab", "get", "register"] @@ -223,7 +224,7 @@ cmdline = [self.name] + raise_opt + args if remote or self.background: - inout = open(os.devnull, "r+") + inout = builtins.open(os.devnull, "r+") else: # for TTY browsers, we need stdin/out inout = None ---------- components: Library (Lib) messages: 76931 nosy: schmichael severity: normal status: open title: webbrowser.UnixBrowser should use builtins.open type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:51:13 2008 From: report at bugs.python.org (Roy Smith) Date: Thu, 04 Dec 2008 21:51:13 +0000 Subject: [issue4538] ctypes could include data type limits In-Reply-To: <1228427473.9.0.217264981204.issue4538@psf.upfronthosting.co.za> Message-ID: <1228427473.9.0.217264981204.issue4538@psf.upfronthosting.co.za> New submission from Roy Smith : It would be useful if ctypes included limiting constants for the various fixed-size integers, i.e. MAX_INT_32, MIN_INT_32, etc. Maybe it does and I just missed just didn't see it in the docs? ---------- assignee: theller components: ctypes messages: 76932 nosy: roysmith, theller severity: normal status: open title: ctypes could include data type limits type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:54:52 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 04 Dec 2008 21:54:52 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <1228425803.9.0.485448222858.issue4506@psf.upfronthosting.co.za> Message-ID: <18744.20903.328677.738582@montanaro-dyndns-org.local> Skip Montanaro added the comment: Mark> Thanks for the assembly code---you're running Solaris on x86! Why Mark> didn't you say so before? :) I'm failry sure I can find a SPARC here to run it on as well. They are rather few and far between though. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:56:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 04 Dec 2008 21:56:21 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228427781.13.0.889197083898.issue4533@psf.upfronthosting.co.za> Christian Heimes added the comment: The small buffer size in Modules/_fileio.c is one reason for the slowness. $ dd if=/dev/zero of=zeros bs=1MB count=50 $ cat testread.py open("zeros", "rb").read() $ ./python -m cProfile testread.py 40 function calls (39 primitive calls) in 4.246 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.016 0.016 4.246 4.246 :1() 1 0.000 0.000 0.000 0.000 io.py:277(__new__) 2 0.000 0.000 0.000 0.000 io.py:355(flush) 2 0.000 0.000 0.000 0.000 io.py:364(close) 2 0.000 0.000 0.000 0.000 io.py:376(__del__) 1 0.000 0.000 0.000 0.000 io.py:413(_checkReadable) 1 0.000 0.000 0.000 0.000 io.py:614(__init__) 2 0.000 0.000 0.000 0.000 io.py:618(close) 1 0.000 0.000 0.000 0.000 io.py:708(__init__) 1 0.000 0.000 0.000 0.000 io.py:733(flush) 1 0.000 0.000 0.000 0.000 io.py:736(close) 1 0.000 0.000 0.000 0.000 io.py:755(closed) 1 0.000 0.000 0.000 0.000 io.py:82(open) 1 0.000 0.000 0.000 0.000 io.py:896(__init__) 2 0.000 0.000 0.000 0.000 io.py:905(_reset_read_buf) 1 0.021 0.021 4.230 4.230 io.py:909(read) 1 0.000 0.000 4.209 4.209 io.py:920(_read_unlocked) 1 0.000 0.000 0.000 0.000 {built-in method allocate_lock} 2/1 0.000 0.000 4.246 4.246 {built-in method exec} 1 0.000 0.000 0.000 0.000 {built-in method fstat} 2 0.000 0.000 0.000 0.000 {built-in method isinstance} 3 0.000 0.000 0.000 0.000 {built-in method len} 1 0.000 0.000 0.000 0.000 {method '__enter__' of '_thread.lock' objects} 1 0.000 0.000 0.000 0.000 {method 'append' of 'list' objects} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} 1 0.000 0.000 0.000 0.000 {method 'fileno' of '_FileIO' objects} 1 0.000 0.000 0.000 0.000 {method 'isatty' of '_FileIO' objects} 1 0.825 0.825 0.825 0.825 {method 'join' of 'bytes' objects} 2 3.384 1.692 3.384 1.692 {method 'read' of '_FileIO' objects} 1 0.000 0.000 0.000 0.000 {method 'readable' of '_FileIO' objects} $ vi Modules/_fileio.c -#define DEFAULT_BUFFER_SIZE (8*1024) +#define DEFAULT_BUFFER_SIZE (80*1024) $ ./python -m cProfile testread.py 40 function calls (39 primitive calls) in 1.273 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.019 0.019 1.273 1.273 :1() 1 0.000 0.000 0.000 0.000 io.py:277(__new__) 2 0.000 0.000 0.000 0.000 io.py:355(flush) 2 0.000 0.000 0.000 0.000 io.py:364(close) 2 0.000 0.000 0.000 0.000 io.py:376(__del__) 1 0.000 0.000 0.000 0.000 io.py:413(_checkReadable) 1 0.000 0.000 0.000 0.000 io.py:614(__init__) 2 0.000 0.000 0.000 0.000 io.py:618(close) 1 0.000 0.000 0.000 0.000 io.py:708(__init__) 1 0.000 0.000 0.000 0.000 io.py:733(flush) 1 0.000 0.000 0.000 0.000 io.py:736(close) 1 0.000 0.000 0.000 0.000 io.py:755(closed) 1 0.000 0.000 0.000 0.000 io.py:82(open) 1 0.000 0.000 0.000 0.000 io.py:896(__init__) 2 0.000 0.000 0.000 0.000 io.py:905(_reset_read_buf) 1 0.016 0.016 1.254 1.254 io.py:909(read) 1 0.000 0.000 1.238 1.238 io.py:920(_read_unlocked) 1 0.000 0.000 0.000 0.000 {built-in method allocate_lock} 2/1 0.000 0.000 1.273 1.273 {built-in method exec} 1 0.000 0.000 0.000 0.000 {built-in method fstat} 2 0.000 0.000 0.000 0.000 {built-in method isinstance} 3 0.000 0.000 0.000 0.000 {built-in method len} 1 0.000 0.000 0.000 0.000 {method '__enter__' of '_thread.lock' objects} 1 0.000 0.000 0.000 0.000 {method 'append' of 'list' objects} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} 1 0.000 0.000 0.000 0.000 {method 'fileno' of '_FileIO' objects} 1 0.000 0.000 0.000 0.000 {method 'isatty' of '_FileIO' objects} 1 1.156 1.156 1.156 1.156 {method 'join' of 'bytes' objects} 2 0.081 0.041 0.081 0.041 {method 'read' of '_FileIO' objects} 1 0.000 0.000 0.000 0.000 {method 'readable' of '_FileIO' objects} _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:06:17 2008 From: report at bugs.python.org (Tim Lesher) Date: Thu, 04 Dec 2008 22:06:17 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228428377.56.0.0904013776484.issue4483@psf.upfronthosting.co.za> Changes by Tim Lesher : ---------- nosy: +tlesher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:14:22 2008 From: report at bugs.python.org (Andrew Price) Date: Thu, 04 Dec 2008 22:14:22 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228428862.01.0.13220984757.issue4483@psf.upfronthosting.co.za> Changes by Andrew Price : ---------- nosy: +AndyP _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:30:46 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 04 Dec 2008 22:30:46 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228429846.26.0.771283690948.issue4534@psf.upfronthosting.co.za> David W. Lambert added the comment: Try this--- def List_to_String(lis,separator=''): return separator.join(lis) ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:35:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 04 Dec 2008 22:35:13 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228430113.36.0.877157019623.issue4533@psf.upfronthosting.co.za> Christian Heimes added the comment: The fileio_buffer.patch implements the same progressive buffer as Python 2.x' Object/fileobject.c. ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file12227/fileio_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:39:19 2008 From: report at bugs.python.org (Andrew Price) Date: Thu, 04 Dec 2008 22:39:19 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228430359.74.0.0409554496752.issue4483@psf.upfronthosting.co.za> Andrew Price added the comment: I'm running the same distro as Leger and I was having the same problem. Now I've applied dbm.diff and with a clean build I'm seeing this: building '_dbm' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_GDBM_DASH_NDBM_H -I. -I/home/andy/src/python3/Python-3.0/./Include -I. -IInclude -I../Include -I/usr/local/include -I/home/andy/src/python3/Python-3.0/debug/Include -I/home/andy/src/python3/Python-3.0/debug -c /home/andy/src/python3/Python-3.0/Modules/_dbmmodule.c -o build/temp.linux-i686-3.0/home/andy/src/python3/Python-3.0/Modules/_dbmmodule.o gcc -pthread -shared build/temp.linux-i686-3.0/home/andy/src/python3/Python-3.0/Modules/_dbmmodule.o -L/usr/local/lib -lgdbm -o build/lib.linux-i686-3.0/_dbm.so *** WARNING: renaming "_dbm" since importing it failed: build/lib.linux-i686-3.0/_dbm.so: undefined symbol: dbm_firstkey _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:40:48 2008 From: report at bugs.python.org (jeff deifik) Date: Thu, 04 Dec 2008 22:40:48 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228430448.92.0.209751756899.issue4534@psf.upfronthosting.co.za> jeff deifik added the comment: Thanks. I want to learn what is wrong with the code I have though. My main goal is to understand python 3.0 better, rather than fixing a specific problem. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:44:29 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 04 Dec 2008 22:44:29 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228430669.85.0.204207217844.issue4534@psf.upfronthosting.co.za> David W. Lambert added the comment: I did this to find out what are str.join's arguments--- $ python3 -c 'help(str.join)' Help on method_descriptor: join(...) S.join(sequence) -> str Return a string which is the concatenation of the strings in the sequence. The separator between elements is S. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:50:35 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 04 Dec 2008 22:50:35 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228431035.03.0.112028466492.issue4533@psf.upfronthosting.co.za> Gregory P. Smith added the comment: patch looks good to me. nitpick comments: use += instead of = and + in: newsize = newsize + newsize and newsize = newsize + BIGCHUNK. As for the XXX about overflow, so long as BUFSIZ is not defined to be an insanely large number (it should never be) this will be fine. add a preprocessor test for that in. #if (BUFSIZ >= 2**30) #error "unreasonable BUFSIZ defined" #endif ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:05:16 2008 From: report at bugs.python.org (Chad Spratt) Date: Thu, 04 Dec 2008 23:05:16 +0000 Subject: [issue4539] askdirectory() in tkinter.filedialog is broken In-Reply-To: <1228431916.65.0.748760497567.issue4539@psf.upfronthosting.co.za> Message-ID: <1228431916.65.0.748760497567.issue4539@psf.upfronthosting.co.za> New submission from Chad Spratt : Calls to tkinter.filedialog.askdirectory() throw a KeyError if any of the options (title, text, bitmap, default, strings) are not provided. Previously saying "askdirectory()" with no arguments would open a file browser window. Since all other functions in filedialog still function with no arguments this seems like an error. (Actually askopenfiles() seems to be broken too, saying "IOError: [Errno 2] No such file or directory: '{'") ---------- components: Tkinter messages: 76941 nosy: dogtato severity: normal status: open title: askdirectory() in tkinter.filedialog is broken type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:14:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 04 Dec 2008 23:14:12 +0000 Subject: [issue4532] Fails to build on QNX 6.3.2 In-Reply-To: <1228415114.24.0.8798028778.issue4532@psf.upfronthosting.co.za> Message-ID: <1228432452.62.0.185949281946.issue4532@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why is this a release blocker? QNX is not a supported platform, so failures on it cannot possibly block a release. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:14:23 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 04 Dec 2008 23:14:23 +0000 Subject: [issue4530] IDLE crashes with Japanese text on print command In-Reply-To: <1228412648.37.0.825902447476.issue4530@psf.upfronthosting.co.za> Message-ID: <1228432463.17.0.618004048261.issue4530@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This is already tracked by issue4008 ---------- nosy: +amaury.forgeotdarc resolution: -> duplicate status: open -> closed superseder: -> IDLE: checksyntax() doesn't support Unicode? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:37:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 04 Dec 2008 23:37:52 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228433872.47.0.312082388889.issue4533@psf.upfronthosting.co.za> Christian Heimes added the comment: The preprocessor doesn't handle power. 2 << 24 (64MB) sounds sufficient for me. Added file: http://bugs.python.org/file12228/fileio_buffer2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:38:43 2008 From: report at bugs.python.org (John Weldon) Date: Thu, 04 Dec 2008 23:38:43 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> Message-ID: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> New submission from John Weldon : Traceback (most recent call last): File "", line 1, in File "c:\Python30\lib\site.py", line 427, in __call__ return pydoc.help(*args, **kwds) File "c:\Python30\lib\pydoc.py", line 1675, in __call__ self.interact() File "c:\Python30\lib\pydoc.py", line 1693, in interact self.help(request) File "c:\Python30\lib\pydoc.py", line 1711, in help self.listmodules(request.split()[1]) File "c:\Python30\lib\pydoc.py", line 1799, in listmodules apropos(key) File "c:\Python30\lib\pydoc.py", line 1913, in apropos ModuleScanner().run(callback, key, onerror=onerror) File "c:\Python30\lib\pydoc.py", line 1875, in run source = loader.get_source(modname) File "c:\Python30\lib\pkgutil.py", line 293, in get_source self.source = self.file.read() File "c:\Python30\lib\io.py", line 1720, in read decoder = self._decoder or self._get_decoder() File "c:\Python30\lib\io.py", line 1506, in _get_decoder make_decoder = codecs.getincrementaldecoder(self._encoding) File "c:\Python30\lib\codecs.py", line 960, in getincrementaldecoder decoder = lookup(encoding).incrementaldecoder LookupError: unknown encoding: uft-8 ---------- files: python3bug.png messages: 76945 nosy: john.weldon severity: normal status: open title: typo in a module describes utf-8 as uft-8 type: crash versions: Python 3.0 Added file: http://bugs.python.org/file12229/python3bug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:51:44 2008 From: report at bugs.python.org (gumpy) Date: Thu, 04 Dec 2008 23:51:44 +0000 Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> Message-ID: <1228434704.52.0.536811595593.issue4537@psf.upfronthosting.co.za> gumpy added the comment: I'd suggest the same thing that was done on lines 351-352. Index: Lib/webbrowser.py =================================================================== --- Lib/webbrowser.py (revision 67538) +++ Lib/webbrowser.py (working copy) @@ -223,7 +223,8 @@ cmdline = [self.name] + raise_opt + args if remote or self.background: - inout = open(os.devnull, "r+") + import io + inout = io.open(os.devnull, "r+") else: # for TTY browsers, we need stdin/out inout = None ---------- nosy: +gumpy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:58:13 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 04 Dec 2008 23:58:13 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228435093.07.0.510644011671.issue4536@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The analysis is good, but there are two problems with your patch: - it crashes in debug mode, because a Py_INCREF(step) is missing in validate_step() (A comment above says: "Always returns a new reference") - it does not work with >>> class Index: ... def __index__(self): ... return 42 ... >>> list(range(0, 100, Index())) TypeError: unsupported operand type(s) for //: 'int' and 'Index' In short: PyNumber_Index is not an unnecessary call! But this does not invalidate the other parts of the patch. Would you try again? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:07:38 2008 From: report at bugs.python.org (Andrew Price) Date: Fri, 05 Dec 2008 00:07:38 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228435658.04.0.317598727967.issue4483@psf.upfronthosting.co.za> Andrew Price added the comment: In Debian Lenny libgbdm-dev provides two libs, libgdbm and libgdbm_compat: andy at plato:~$ objdump -t /usr/lib/libgdbm.a | grep dbm_firstkey 00000000 *UND* 00000000 gdbm_firstkey 00000140 g F .text 00000056 gdbm_firstkey andy at plato:~$ objdump -t /usr/lib/libgdbm_compat.a | grep dbm_firstkey 00000000 *UND* 00000000 gdbm_firstkey 00000000 g F .text 00000060 dbm_firstkey 00000000 *UND* 00000000 gdbm_firstkey So it looks like we need to link against -lgdbm_compat instead of -lgdbm for the _dbm module. I'm attaching dbm3.diff which seems to fix the problem (I did a test build with it). Added file: http://bugs.python.org/file12230/dbm3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:11:59 2008 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 05 Dec 2008 00:11:59 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228430359.74.0.0409554496752.issue4483@psf.upfronthosting.co.za> Message-ID: <18744.29131.428234.581387@montanaro-dyndns-org.local> Skip Montanaro added the comment: Andrew> I'm running the same distro as Leger and I was having the same Andrew> problem. Now I've applied dbm.diff and with a clean build I'm Andrew> seeing this: ... Andrew> *** WARNING: renaming "_dbm" since importing it failed: Andrew> build/lib.linux-i686-3.0/_dbm.so: undefined symbol: dbm_firstkey It looks like we might need to be linking with -lgdbm_compat as well as -lgdbm. Can you attach the output of these commands objdump -T /usr/lib/libgdbm.so.N objdump -T /usr/lib/libgdbm_compat.so.N to this issue (where N is the highest version available)? Thanks, _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:18:14 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 00:18:14 +0000 Subject: [issue4522] Module wsgiref is not python3000 ready (unicode issues) In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za> Message-ID: <1228436294.49.0.114943598869.issue4522@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The patch is incomplete: it breaks test_wsgiref. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:24:48 2008 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 05 Dec 2008 00:24:48 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228436688.51.0.797736714872.issue4483@psf.upfronthosting.co.za> Skip Montanaro added the comment: Here's a new version of the patch for Python 3.0. It appends gdbm_compat to the gdbm libs if that's where dbm_firstkey is defined. Please back out the previous patch against setup.py and Modules/_dbmmodule.c and apply this one. Thanks... Added file: http://bugs.python.org/file12231/dbm.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:25:14 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 00:25:14 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228436714.49.0.222007998751.issue4534@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: >>> str.join(lis, '') I doubt this really worked with 2.6. Wasn't it something like: >>> import string >>> string.join(lis, '') ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:33:34 2008 From: report at bugs.python.org (Zach Hirsch) Date: Fri, 05 Dec 2008 00:33:34 +0000 Subject: [issue4541] Add str method for removing leading or trailing substrings In-Reply-To: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za> Message-ID: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za> New submission from Zach Hirsch : I've found that having a way to strip a leading substring from a string is convienent. I've also gotten bitten by the fact that str.strip takes a sequence of characters to remove from the beginning -- not a full string. I've attached a patch that implements lstrips, rstrips, and strips on str, unicode, and as methods in the string module. I'm not particularly attached to the names. Please consider this patch for inclusion in Python. Thanks! ---------- components: Library (Lib) files: lstrips-67529.patch keywords: patch messages: 76953 nosy: zhirsch severity: normal status: open title: Add str method for removing leading or trailing substrings type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file12232/lstrips-67529.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:33:38 2008 From: report at bugs.python.org (Laszlo) Date: Fri, 05 Dec 2008 00:33:38 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228437218.38.0.59653903389.issue4536@psf.upfronthosting.co.za> Laszlo added the comment: Oops, sorry I didn't realize validate_step() is supposed to validate the input AND return the converted value. Thanks for the feedback. This new patch should work fine. It retains only the two final points of the previous patch; it doesn't clear the error, and it checks for other NULL values before calling validate_step(). Added file: http://bugs.python.org/file12233/range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:33:43 2008 From: report at bugs.python.org (Laszlo) Date: Fri, 05 Dec 2008 00:33:43 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228437223.86.0.757519409392.issue4536@psf.upfronthosting.co.za> Changes by Laszlo : Removed file: http://bugs.python.org/file12226/range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:47:50 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 00:47:50 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> Message-ID: <1228438070.05.0.984286595262.issue4540@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: When enumerating all possible modules, the help system tries to import test.bad_coding.py :-( I tried to catch this LookupError, but then it fail on test.badsyntax_pep3120.py, with a SyntaxError Traceback (most recent call last): File "", line 1, in File "C:\Python30\lib\site.py", line 427, in __call__ return pydoc.help(*args, **kwds) File "c:\python30\lib\pydoc.py", line 1675, in __call__ self.interact() File "c:\python30\lib\pydoc.py", line 1693, in interact self.help(request) File "c:\python30\lib\pydoc.py", line 1711, in help self.listmodules(request.split()[1]) File "c:\python30\lib\pydoc.py", line 1799, in listmodules apropos(key) File "c:\python30\lib\pydoc.py", line 1913, in apropos ModuleScanner().run(callback, key, onerror=onerror) File "c:\python30\lib\pydoc.py", line 1872, in run loader = importer.find_module(modname) File "C:\Python30\lib\pkgutil.py", line 186, in find_module file, filename, etc = imp.find_module(subname, path) SyntaxError: Non-UTF-8 code starting with '\xf6' in file (null) on line 1, but n o encoding declared; see http://python.org/dev/peps/pep-0263/ for details [Note: I don't like the (null) as a filename...] ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:59:18 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 00:59:18 +0000 Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> Message-ID: <1228438758.52.0.924500205616.issue4537@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- assignee: -> amaury.forgeotdarc nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:00:22 2008 From: report at bugs.python.org (Andrew Price) Date: Fri, 05 Dec 2008 01:00:22 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228438822.63.0.92887227954.issue4483@psf.upfronthosting.co.za> Andrew Price added the comment: Skip, the new patch makes it fail with (highlights): ... File "/home/andy/src/python3/Python-3.0/Lib/distutils/ccompiler.py", line 844, in has_function import tempfile File "/home/andy/src/python3/Python-3.0/Lib/tempfile.py", line 35, in from random import Random as _Random File "/home/andy/src/python3/Python-3.0/Lib/random.py", line 42, in from math import log as _log, exp as _exp, pi as _pi, e as _e, ceil as _ceil ImportError: No module named math make: *** [sharedmods] Error 1 The has_function source in Lib/distutils/ccompiler.py has this comment: # this can't be included at module scope because it tries to # import math which might not be available at that point - maybe # the necessary logic should just be inlined? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:08:18 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 01:08:18 +0000 Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> Message-ID: <1228439298.16.0.514330466107.issue4537@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Fixed in 67539 (py3k) and 67540 (release30-maint) Thanks for the report! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:16:39 2008 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 05 Dec 2008 01:16:39 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228438822.63.0.92887227954.issue4483@psf.upfronthosting.co.za> Message-ID: <18744.33005.894750.112774@montanaro-dyndns-org.local> Skip Montanaro added the comment: Andrew> ImportError: No module named math Andrew> make: *** [sharedmods] Error 1 Andrew> The has_function source in Lib/distutils/ccompiler.py has this Andrew> comment: Andrew> # this can't be included at module scope because it tries to Andrew> # import math which might not be available at that point - maybe Andrew> # the necessary logic should just be inlined? *sigh* I guess that would explain why it wasn't used anywhere in setup.py. Can you try this simplified version? (It's probably almost exactly what you came up with.) Thanks, Skip Added file: http://bugs.python.org/file12234/dbm.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dbm.diff URL: From report at bugs.python.org Fri Dec 5 02:17:53 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 01:17:53 +0000 Subject: [issue4541] Add str method for removing leading or trailing substrings In-Reply-To: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za> Message-ID: <1228439873.43.0.398088596463.issue4541@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I cannot say if this new set of function is desirable in python, but I know that I already needed this feature sometimes. It's very easy to write in python code, though: def rstrips(s, suffix): if suffix and s.endswith(suffix): s = s[:-len(suffix)] return s About the patch: - there is a reference leak in string_strips: lstripped must be decref'd - this both-ends function seems less useful: prefixes are often different from suffixes. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:23:40 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 01:23:40 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228440220.01.0.608250294074.issue4536@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The new patch is good for me. I added unit tests, someone should review. ---------- keywords: +needs review stage: -> patch review Added file: http://bugs.python.org/file12235/test_range.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:27:07 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 01:27:07 +0000 Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za> Message-ID: <1228440427.71.0.815472681342.issue3890@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > there must be a better way of handling the recv() case This is a completely unrelated issue IMO; and FWIW, io.open() is not better in this aspect. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:35:24 2008 From: report at bugs.python.org (Andrew Price) Date: Fri, 05 Dec 2008 01:35:24 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228440924.36.0.672130467257.issue4483@psf.upfronthosting.co.za> Andrew Price added the comment: Skip, your simplified patch works for me. Makes it build fine with the following snippet: building '_dbm' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_GDBM_DASH_NDBM_H -I. -I/home/andy/src/python3/Python-3.0/./Include -I. -IInclude -I../Include -I/usr/local/include -I/home/andy/src/python3/Python-3.0/debug/Include -I/home/andy/src/python3/Python-3.0/debug -c /home/andy/src/python3/Python-3.0/Modules/_dbmmodule.c -o build/temp.linux-i686-3.0/home/andy/src/python3/Python-3.0/Modules/_dbmmodule.o gcc -pthread -shared build/temp.linux-i686-3.0/home/andy/src/python3/Python-3.0/Modules/_dbmmodule.o -L/usr/local/lib -lgdbm -lgdbm_compat -o build/lib.linux-i686-3.0/_dbm.so Thanks. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:36:54 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 01:36:54 +0000 Subject: [issue4542] test_binascii fails on windows In-Reply-To: <1228441014.26.0.452490077476.issue4542@psf.upfronthosting.co.za> Message-ID: <1228441014.26.0.452490077476.issue4542@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : issue #4387 (67472) changed binascii and added tests, but the windows specific implementation was not changed. Change is trivial: Index: Modules/binascii.c =================================================================== --- Modules/binascii.c (revision 67538) +++ Modules/binascii.c (working copy) @@ -1019,7 +1019,7 @@ Py_ssize_t len; unsigned int result; - if ( !PyArg_ParseTuple(args, "s*|I:crc32", &pbin, &crc) ) + if ( !PyArg_ParseTuple(args, "y*|I:crc32", &pbin, &crc) ) return NULL; bin_data = pbin.buf; len = pbin.len; ---------- components: Windows keywords: easy, patch messages: 76963 nosy: amaury.forgeotdarc severity: normal status: open title: test_binascii fails on windows versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:42:16 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 01:42:16 +0000 Subject: [issue4542] test_binascii fails on windows In-Reply-To: <1228441014.26.0.452490077476.issue4542@psf.upfronthosting.co.za> Message-ID: <1228441336.78.0.788321384228.issue4542@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Fixed in r67541 (py3k) and r67542 (release30-maint) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:44:06 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 01:44:06 +0000 Subject: [issue4514] test_binascii is failing In-Reply-To: <1228360519.8.0.091239531214.issue4514@psf.upfronthosting.co.za> Message-ID: <1228441446.65.0.559441596812.issue4514@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I fixed this in r67541 and r67542, with issue4542. (sorry I did not see this one) ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed superseder: -> test_binascii fails on windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:45:04 2008 From: report at bugs.python.org (Zach Hirsch) Date: Fri, 05 Dec 2008 01:45:04 +0000 Subject: [issue4541] Add str method for removing leading or trailing substrings In-Reply-To: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za> Message-ID: <1228441504.8.0.800155756496.issue4541@psf.upfronthosting.co.za> Zach Hirsch added the comment: Thanks for taking a look. Yea, it's pretty easy to write it in Python, but I've found that I've needed it in quite a few things that I've worked on, so I thought it might be useful in Python itself. I've updated the patch to fix the reference leak. I could imagine someone wanting to strip the same string from both sides, e.g. "-- hello --".strips('--').strip() == "hello". It might also be a good idea to include str.strips for parallelism with str.strip. Added file: http://bugs.python.org/file12236/lstrips-67529.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 03:00:21 2008 From: report at bugs.python.org (jeff deifik) Date: Fri, 05 Dec 2008 02:00:21 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228442421.07.0.777953717349.issue4534@psf.upfronthosting.co.za> jeff deifik added the comment: Yes, it was import string string.join(lis, '') I am still a bit confused though. Why doesn't my code of str.join(lis, '') work? I don't think str is a reserved word. I suppose that python might be able to deduce that str is of type string, based on join being called on it. Is the problem that python thinks my str is of type list? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 03:19:43 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 05 Dec 2008 02:19:43 +0000 Subject: [issue4522] Module wsgiref is not python3000 ready (unicode issues) In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za> Message-ID: <1228443583.11.0.230755208983.issue4522@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +pje _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 04:47:33 2008 From: report at bugs.python.org (Michael Schurter) Date: Fri, 05 Dec 2008 03:47:33 +0000 Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> Message-ID: <1228448853.21.0.487809502751.issue4537@psf.upfronthosting.co.za> Michael Schurter added the comment: I believe you forgot to "import io" in UnixBrowser (line 226). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 07:08:47 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 05 Dec 2008 06:08:47 +0000 Subject: [issue4519] .pyc files included in 2.6 and 3.0 release tarballs In-Reply-To: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za> Message-ID: <1228457327.79.0.101528848925.issue4519@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Actually, it turns out that the doc build process leaves a few more pyc turds now. I've updated release.py to remove them, though the script really should complain loudly if it ever finds pycs in the distribution. That's for next time. Fortunately, it's only 3 pycs so I see no reason why a new release needs to be cut. The Python 2.6.1 tarballs don't have them and neither will the 3.0.1 tarballs when they're released. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:33:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 07:33:04 +0000 Subject: [issue4355] Error in docs of urllib.request and urllib.parse In-Reply-To: <1227111594.24.0.921624476893.issue4355@psf.upfronthosting.co.za> Message-ID: <1228462384.36.0.982915347964.issue4355@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed in r67551. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:43:32 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 05 Dec 2008 07:43:32 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228463012.26.0.384323451036.issue4533@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fileio_buffer2.patch looks good other than minor touchups: Turn the XXX comment into: /* NOTE: overflow impossible due to limits on BUFSIZ * Also, 2 << 24 is 32MB yet your error message test says >= 64MB. I think you meant 1 << 26. fix those and commit. :) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:46:21 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 07:46:21 +0000 Subject: [issue4401] os.extsep status? doc or os bug? In-Reply-To: <1227489891.63.0.655964178885.issue4401@psf.upfronthosting.co.za> Message-ID: <1228463181.52.0.393194943321.issue4401@psf.upfronthosting.co.za> Georg Brandl added the comment: Re-added os.extsep to the os module in r67552. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:50:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 07:50:02 +0000 Subject: [issue4408] re.compile(regexp).groups not documented In-Reply-To: <1227528971.48.0.179981852127.issue4408@psf.upfronthosting.co.za> Message-ID: <1228463402.19.0.427408198965.issue4408@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67553. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:52:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 07:52:35 +0000 Subject: [issue4409] Dangling asterisks in Python 3.0 subprocess docs In-Reply-To: <18730.50503.956524.686132@montanaro-dyndns-org.local> Message-ID: <1228463555.57.0.119991676505.issue4409@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be fixed in r67554. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:53:41 2008 From: report at bugs.python.org (Kevin J. Woolley) Date: Fri, 05 Dec 2008 07:53:41 +0000 Subject: [issue4543] container constructors destroy argument In-Reply-To: <1228463620.98.0.983190950488.issue4543@psf.upfronthosting.co.za> Message-ID: <1228463620.98.0.983190950488.issue4543@psf.upfronthosting.co.za> New submission from Kevin J. Woolley : Doing the following (more info than necessary in case I'm doing something weird): def odd(n): return n % 2 x = (1, 2, 3, 4, 5) y = filter(odd, x) list(y) list(y) Will correctly build a list from y and return [1, 3, 5] on the first call to list(), but will return an empty list thereafter. y still identifies itself as a filter object, but you either can't coerce it to anything else or the value of the filter object is reset (I don't know how to tell the difference yet). The other container constructors (set, tuple, etc.) seem to have the same behaviour. ---------- components: Library (Lib) messages: 76975 nosy: kjwcode severity: normal status: open title: container constructors destroy argument type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:58:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 07:58:01 +0000 Subject: [issue4427] Docs for 'y' Py_BuildValue tag are wrong In-Reply-To: <1228463881.35.0.545007371974.issue4427@psf.upfronthosting.co.za> Message-ID: <1228463881.35.0.545007371974.issue4427@psf.upfronthosting.co.za> New submission from Georg Brandl : Applied in r67555. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:00:18 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 05 Dec 2008 08:00:18 +0000 Subject: [issue4543] container constructors destroy argument In-Reply-To: <1228463620.98.0.983190950488.issue4543@psf.upfronthosting.co.za> Message-ID: <1228464018.17.0.633376721838.issue4543@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In Py3.0, the filter() builtin returns a consumable iterator, not a list. It's a feature, not a bug ;-) For the behavior you want, write: y = list(filter(odd, x)) Or better yet, use a list comprehension: y = [e for e in x if odd(e)] See the Whatsnew section of the docs for further explanation. ---------- nosy: +rhettinger resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:02:59 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 08:02:59 +0000 Subject: [issue4441] Improve os open flag options doc In-Reply-To: <1227716510.76.0.255210544694.issue4441@psf.upfronthosting.co.za> Message-ID: <1228464179.32.0.370179611533.issue4441@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67556. If a Windows guy can give me more specific directions where to find the equivalent options, I'll put it in. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:06:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 08:06:41 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1228464401.88.0.0405217095873.issue4442@psf.upfronthosting.co.za> Georg Brandl added the comment: It's not documented for any immutable type. This should be fixed. ---------- title: datetime not subclassable in the usual way -> document immutable type subclassing via __new__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:13:59 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 08:13:59 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228464839.66.0.661842164648.issue4534@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: "str" is not your string, it's not a string; "str" is a class name, a standard type. "str.join" is a unbound method. You can call it directly if you pass an actual string object in front of the other arguments. But the normal way to call methods is to use them on objects: someString = "" someList = ['f', 'r', 'e', 'd', ' ', 'i', 's'] someString.join(someList) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:33:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 05 Dec 2008 08:33:26 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228466006.11.0.989527519821.issue4533@psf.upfronthosting.co.za> Christian Heimes added the comment: The updated patch has been committed to 3.0 and 3.1. I'm going to backport the patch to 2.x later. ---------- resolution: -> accepted stage: patch review -> commit review versions: +Python 2.6, Python 2.7 -Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:34:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 08:34:53 +0000 Subject: [issue4468] Restore chapter enumeration in Python docs In-Reply-To: <1228035455.3.0.341155403545.issue4468@psf.upfronthosting.co.za> Message-ID: <1228466093.06.0.289530405349.issue4468@psf.upfronthosting.co.za> Georg Brandl added the comment: This is tracked in Sphinx' tracker at http://www.bitbucket.org/birkenfeld/sphinx/issue/10/html-section-numbering. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:35:09 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 08:35:09 +0000 Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> Message-ID: <1228466109.4.0.981524748885.issue4537@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: sorry**10... probably a wrong copy operation because the Linux machine where I tested did not have my svn ssh keys. Someone already corrected this on py3k (r67544, thanks to Fred!), I'll take care of merging it to the 3.0 branch. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:52:49 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 08:52:49 +0000 Subject: [issue4441] Improve os open flag options doc In-Reply-To: <1227716510.76.0.255210544694.issue4441@psf.upfronthosting.co.za> Message-ID: <1228467169.6.0.101899560088.issue4441@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx is the documentation for the open() function of the Microsoft C Runtime, but I don't know how permanent this link will be. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:01:51 2008 From: report at bugs.python.org (David W. Lambert) Date: Fri, 05 Dec 2008 09:01:51 +0000 Subject: [issue4541] Add str method for removing leading or trailing substrings In-Reply-To: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za> Message-ID: <1228467711.09.0.482728509347.issue4541@psf.upfronthosting.co.za> David W. Lambert added the comment: Opinion---"Batteries included" doesn't mean "a bewildering variety of functions". Nor does it mean "my programming language has a checklist of features" such as I recall the spreadsheet and word processor wars of the (19)80's. Python should indeed make it easy to express your algorithms. It does this through readable syntax, by providing container objects of all sorts, with malleable classes. It gives access to operating system and hardware. Python stays current with softwares of the day. But Python should remain small It's okay to write some code. Must regular expression syntax keep pace with that of perl? Probably, only because the expressions are directly cut and pasteable. Otherwise, the re language has for me exceeded in complexity that which can be had more simply with a divide and conquer approach. Is there a good reason to have the math module duplicate the functionality described in math.h? No. One needn't know the c language exists to program python. (Historically it was a great and obvious first access to math functions in python. We're years beyond that. Hence---generalize hypot. It's brain dead trapped in 2D!) Don't accept the challenge for a python vs. (for instance) ruby feature checklist. Python should stick to the sensible. ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:02:58 2008 From: report at bugs.python.org (Casey McGinty) Date: Fri, 05 Dec 2008 09:02:58 +0000 Subject: [issue4544] textwrap: __all__ atribute missing 'dedent' functino In-Reply-To: <1228467778.52.0.173118207596.issue4544@psf.upfronthosting.co.za> Message-ID: <1228467778.52.0.173118207596.issue4544@psf.upfronthosting.co.za> New submission from Casey McGinty : >From textwrap.py: 46863 2006-06-11 19:42:51Z tim.peters The __all__ define in this module is missing the helper function 'dedent'. This causes pydoc to not the list the function correctly. Secondly, it also prevents 'dedent' from being imported when using 'from textwrap import *' (Yes, yes, I know this should never be done. Hence why it is probably never noticed by anyone.) ---------- components: Extension Modules messages: 76986 nosy: wolfdown severity: normal status: open title: textwrap: __all__ atribute missing 'dedent' functino type: feature request versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:03:21 2008 From: report at bugs.python.org (Casey McGinty) Date: Fri, 05 Dec 2008 09:03:21 +0000 Subject: [issue4544] textwrap: __all__ atribute missing 'dedent' function In-Reply-To: <1228467778.52.0.173118207596.issue4544@psf.upfronthosting.co.za> Message-ID: <1228467801.09.0.078299020276.issue4544@psf.upfronthosting.co.za> Changes by Casey McGinty : ---------- title: textwrap: __all__ atribute missing 'dedent' functino -> textwrap: __all__ atribute missing 'dedent' function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:19:28 2008 From: report at bugs.python.org (Zach Hirsch) Date: Fri, 05 Dec 2008 09:19:28 +0000 Subject: [issue4541] Add str method for removing leading or trailing substrings In-Reply-To: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za> Message-ID: <1228468768.08.0.00281389167938.issue4541@psf.upfronthosting.co.za> Zach Hirsch added the comment: Sounds good to me, except for one thing: define "sensible". To me, lstrips seems sensible, since it's a recurring pattern that I've used in multiple locations. But perhaps my sense of sensibility is warped :) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:21:18 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 05 Dec 2008 09:21:18 +0000 Subject: [issue3873] Unpickling is really slow In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za> Message-ID: <1228468878.03.0.819991007434.issue3873@psf.upfronthosting.co.za> Hagen F?rstenau added the comment: I think a read buffer is not possible without being able to unread bytes from the stream. pickle shoudn't consume bytes after the end of a pickled object! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:23:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:23:44 +0000 Subject: [issue4458] getopt.gnu_getopt() loses dash argument In-Reply-To: <1227935040.48.0.357266334466.issue4458@psf.upfronthosting.co.za> Message-ID: <1228469024.11.0.612321826311.issue4458@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67572. I won't backport this. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:26:00 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:26:00 +0000 Subject: [issue4441] Improve os open flag options doc In-Reply-To: <1227716510.76.0.255210544694.issue4441@psf.upfronthosting.co.za> Message-ID: <1228469160.91.0.497964559181.issue4441@psf.upfronthosting.co.za> Georg Brandl added the comment: Added link in r67574. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:27:28 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:27:28 +0000 Subject: [issue1675334] Draft implementation for PEP 364 Message-ID: <1228469248.39.0.915396356531.issue1675334@psf.upfronthosting.co.za> Georg Brandl added the comment: Ping! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:29:56 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:29:56 +0000 Subject: [issue1777458] glob doesn't return unicode with unicode parameter Message-ID: <1228469396.51.0.719230539425.issue1777458@psf.upfronthosting.co.za> Georg Brandl added the comment: I see the same as Antoine, this is fixed in 2.6. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:32:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:32:44 +0000 Subject: [issue1762972] 'exec' does not accept what 'open' returns Message-ID: <1228469564.63.0.251364848634.issue1762972@psf.upfronthosting.co.za> Georg Brandl added the comment: All open items in this issue seem to be addressed ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:36:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:36:19 +0000 Subject: [issue1143] Update to latest ElementTree in Python 2.7 In-Reply-To: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za> Message-ID: <1228469779.57.0.564760741147.issue1143@psf.upfronthosting.co.za> Georg Brandl added the comment: I guess this is now an item for Python 2.7. ---------- nosy: +georg.brandl title: Update to latest ElementTree in Python 2.6 -> Update to latest ElementTree in Python 2.7 versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:37:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:37:50 +0000 Subject: [issue1643369] pdb find_function does not find Class methods. Message-ID: <1228469870.15.0.504429637229.issue1643369@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:42:14 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:42:14 +0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1228470134.48.0.581674090782.issue1215@psf.upfronthosting.co.za> Georg Brandl added the comment: The docs already say "Because the C signal handler always returns, it makes little sense to catch synchronous errors like :const:`SIGFPE` or :const:`SIGSEGV`." Should this still be reworded or promoted to a warning? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:43:30 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:43:30 +0000 Subject: [issue1223] httplib does not handle ssl end of file properly In-Reply-To: <1191199809.02.0.233978380017.issue1223@psf.upfronthosting.co.za> Message-ID: <1228470210.8.0.274354008215.issue1223@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:46:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:46:32 +0000 Subject: [issue1366] popen spawned process may not write to stdout under windows In-Reply-To: <1193824783.73.0.865697244253.issue1366@psf.upfronthosting.co.za> Message-ID: <1228470392.86.0.107947896785.issue1366@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:48:18 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 05 Dec 2008 09:48:18 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> Message-ID: <1228470498.75.0.949870007847.issue4540@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Amaury, I don't see where imp.find_module() tries to do a compile() (which would trigger the SyntaxError). Is that really the full traceback ? Regarding the strategy of pydoc to try to list all modules: I don't think that's such a good idea. It's likely to take a long time to compile such a list on a moderately used Python system and can have lots of unwanted side effects via import hooks. Instead, pydoc should just say that a module was not specified and be done with it. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:52:05 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:52:05 +0000 Subject: [issue2311] Update the ACKS file In-Reply-To: <1205702821.59.0.0634295065395.issue2311@psf.upfronthosting.co.za> Message-ID: <1228470725.92.0.746674178276.issue2311@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:54:49 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 05 Dec 2008 09:54:49 +0000 Subject: [issue4541] Add str method for removing leading or trailing substrings In-Reply-To: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za> Message-ID: <1228470889.06.0.907212589263.issue4541@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I agree with Lambert. Am rejecting this one on the basis that it adds too little value, is too easily accomplished with pure python, and that it makes the list of string methods unnecessarily more complex and harder to learn. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:57:14 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:57:14 +0000 Subject: [issue2393] Backport buffer interface in Python 3.0 to Python 2.6 In-Reply-To: <1205855698.81.0.786586368885.issue2393@psf.upfronthosting.co.za> Message-ID: <1228471034.54.0.644609383244.issue2393@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:59:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 09:59:01 +0000 Subject: [issue2447] Python 2.6 refleak test issues In-Reply-To: <1206125520.14.0.711672473194.issue2447@psf.upfronthosting.co.za> Message-ID: <1228471141.31.0.913060334232.issue2447@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> duplicate status: open -> closed superseder: -> regrtest.py -R not working _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:13:24 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 10:13:24 +0000 Subject: [issue3256] Multiprocessing docs are not 3.0-ready In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za> Message-ID: <1228472004.01.0.874221836716.issue3256@psf.upfronthosting.co.za> Georg Brandl added the comment: The docstrings are now fixed too. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:24:57 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 10:24:57 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> Message-ID: <1228472697.82.0.196133074797.issue4540@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes, it is the full traceback. The modules are not compiled nor imported. But to load the source code, importer.find_module() needs to open the file in text mode, so it calls PyTokenizer_FindEncoding() (this is the second failure, with test.badsyntax_pep3120.py), then the encoding is used to decode text (this is the first failure, with test.bad_coding.py) > Instead, pydoc should just say that a module was not specified > and be done with it. I'm not sure to understand. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:39:39 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 05 Dec 2008 10:39:39 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228472697.82.0.196133074797.issue4540@psf.upfronthosting.co.za> Message-ID: <493904E9.2040500@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-05 11:24, Amaury Forgeot d'Arc wrote: > Amaury Forgeot d'Arc added the comment: > > Yes, it is the full traceback. > > The modules are not compiled nor imported. > But to load the source code, importer.find_module() needs to open the > file in text mode, so it calls PyTokenizer_FindEncoding() (this is the > second failure, with test.badsyntax_pep3120.py), then the encoding is > used to decode text (this is the first failure, with test.bad_coding.py) I see. >> Instead, pydoc should just say that a module was not specified >> and be done with it. > > I'm not sure to understand. Sorry, I didn't see the attached PNG screenshot until now. Forget that comment. What I don't understand is that this works: help> modules Please wait a moment while I gather a list of all available modules... ... while this doesn't: help> modules web Here is a list of matching modules. Enter any module name to get more help. Traceback (most recent call last): ... Shouldn't the first method also cause a traceback ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:49:37 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 10:49:37 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> Message-ID: <1228474177.98.0.791145040782.issue4540@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Explanation is simple: help("modules") just lists all files but do not open them. help("modules web") has to search text inside. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:52:42 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 05 Dec 2008 10:52:42 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228474177.98.0.791145040782.issue4540@psf.upfronthosting.co.za> Message-ID: <493907F7.400@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-05 11:49, Amaury Forgeot d'Arc wrote: > Amaury Forgeot d'Arc added the comment: > > Explanation is simple: > help("modules") just lists all files but do not open them. > help("modules web") has to search text inside. Ok, thanks. What if we skip any errors that occur during this scan ? After all, it's just a help function, not a vital system operation. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 12:18:38 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 11:18:38 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228475918.39.0.85384130998.issue4506@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I'm failry sure I can find a SPARC here to run it on as well. They > are rather few and far between though. I don't think that's necessary. Thanks for disabusing me of my 'Solaris implies SPARC' mindset, though! There are two more pieces of information that *would* be useful: 1. What happens if you build with the '-ffloat-store' option to gcc? If my diagnosis is correct I'd expect the cmath tests to pass with this flag. (I'm not 100% sure how to make sure the '-ffloat-store' option gets passed through into the Module builds, though "BASECFLAGS='-ffloat-store' ./configure" seems to work for me.) 2. It looks as though the configure script isn't finding 'isinf' on Solaris 10. Any ideas why? Is there some replacement for isinf that's spelt differently? I suspect that if we were using the system lib's test for infinity instead of the Py_IS_INFINITY workaround then this problem wouldn't have come up. Mark _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 12:35:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 11:35:13 +0000 Subject: [issue4544] textwrap: __all__ atribute missing 'dedent' function In-Reply-To: <1228467778.52.0.173118207596.issue4544@psf.upfronthosting.co.za> Message-ID: <1228476913.73.0.611007613463.issue4544@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67575, will be ported to all branches. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 12:42:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 11:42:16 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228477336.01.0.72686800541.issue4536@psf.upfronthosting.co.za> Georg Brandl added the comment: Why is the overflow handling changed at all? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 12:45:55 2008 From: report at bugs.python.org (ekorn) Date: Fri, 05 Dec 2008 11:45:55 +0000 Subject: [issue4545] doctest seems to always fail on numpy.array2string In-Reply-To: <1228477555.39.0.103154485661.issue4545@psf.upfronthosting.co.za> Message-ID: <1228477555.39.0.103154485661.issue4545@psf.upfronthosting.co.za> New submission from ekorn : I don't understand this doctest error, resulting from python test_doctest.py Failed example: numpy.array2string(numpy.arange(2)) Expected: [0 1] Got: '[0 1]' The specified output was copied-and-pasted directly from running the example. Whitespace seems identical and #doctest: +NORMALIZE_WHITESPACE does not help. ---------- components: Tests files: test_doctest.py messages: 77006 nosy: ekorn severity: normal status: open title: doctest seems to always fail on numpy.array2string type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file12237/test_doctest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 12:46:50 2008 From: report at bugs.python.org (Charles-Axel Dein) Date: Fri, 05 Dec 2008 11:46:50 +0000 Subject: [issue3722] print followed by exception eats print with doctest In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za> Message-ID: <1228477610.59.0.0150817455721.issue3722@psf.upfronthosting.co.za> Charles-Axel Dein added the comment: This is a bug. This is not a good behavior. If I would like to temporarily print a variable to see its content, in order to debug my code, doctest will eat its output. Thus I will be make to use pdb or to use logging, or to get rid of doctest. This will be far more complicated. See attached file. ---------- nosy: +charlax type: feature request -> behavior Added file: http://bugs.python.org/file12238/proof_of_concept_doctest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 13:10:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 12:10:04 +0000 Subject: [issue4529] parser module failure on valid try/except/finally blocks In-Reply-To: <1228411329.74.0.280169454791.issue4529@psf.upfronthosting.co.za> Message-ID: <1228479004.05.0.776048584304.issue4529@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67576, will be ported to all branches. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 13:28:09 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 12:28:09 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> Message-ID: <1228480089.15.0.0706302083901.issue4540@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Attached patch ignores any Exception during module import. Note that KeyboardInterrupt is not caught: it is not an Exception. I could provide a similar patch for 2.7, if there is some interest; but no crash was reported. ---------- keywords: +needs review, patch stage: -> patch review Added file: http://bugs.python.org/file12239/help_badencoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 13:49:48 2008 From: report at bugs.python.org (James Athey) Date: Fri, 05 Dec 2008 12:49:48 +0000 Subject: [issue3978] ZipFileExt.read() can be incredibly slow; patch included In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za> Message-ID: <1228481388.69.0.137343103916.issue3978@psf.upfronthosting.co.za> Changes by James Athey : ---------- title: ZipFileExt.read() can be incredibly slow -> ZipFileExt.read() can be incredibly slow; patch included _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 13:58:02 2008 From: report at bugs.python.org (Paul Melis) Date: Fri, 05 Dec 2008 12:58:02 +0000 Subject: [issue4546] Small thingy in "What's New in Python 3.0" In-Reply-To: <1228481882.44.0.510834493207.issue4546@psf.upfronthosting.co.za> Message-ID: <1228481882.44.0.510834493207.issue4546@psf.upfronthosting.co.za> New submission from Paul Melis : The second to last item under "Removed Syntax" (about relative imports) shows ReST markup in the HTML file, probably not the way it should read: The only acceptable syntax for relative imports is from .``[*module*] :keyword:`import` *name*; :keyword:`import` forms not starting with ``. are always interpreted as absolute imports. ---------- assignee: georg.brandl components: Documentation messages: 77010 nosy: georg.brandl, paulmelis severity: normal status: open title: Small thingy in "What's New in Python 3.0" versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 14:03:09 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 13:03:09 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228482189.84.0.827174232232.issue4536@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: It's right that the overflow handling path is never never taken: If "step = PyNumber_Index(step)" succeeds, 'step' is (a subclass of) an int, and PyNumber_AsSsize_t cannot fail, not even on low memory conditions, and large figures are clipped. But if it were to fail (in some future implementation), the present code would clear an eventual exception. Maybe this part could be applied only to 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 14:03:41 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 05 Dec 2008 13:03:41 +0000 Subject: [issue1675334] Draft implementation for PEP 364 Message-ID: <1228482221.27.0.792222570593.issue1675334@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Withdrawn ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 14:05:09 2008 From: report at bugs.python.org (fboule) Date: Fri, 05 Dec 2008 13:05:09 +0000 Subject: [issue4547] Long jumps with frame_setlineno In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za> Message-ID: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za> New submission from fboule : This concerns a known bug in the frame_setlineno() function for Python 2.5.x and 2.6.x (maybe in earlier/later version too). It is not possible to use this function when the address or line offset in lnotab are greater than 127. The problem comes from the lnotab variable which is typed char*, i.e. "signed char*" implicitly. Any value above 127 becomes a negative number. The fix is very simple (applied on the Python 2.6.1 version of the source code): --- frameobject.c Thu Oct 02 19:39:50 2008 +++ frameobject_fixed.c Fri Dec 05 11:27:42 2008 @@ -119,8 +119,8 @@ line = f->f_code->co_firstlineno; new_lasti = -1; for (offset = 0; offset < lnotab_len; offset += 2) { - addr += lnotab[offset]; - line += lnotab[offset+1]; + addr += ((unsigned char*)lnotab)[offset]; + line += ((unsigned char*)lnotab)[offset+1]; if (line >= new_lineno) { new_lasti = addr; new_lineno = line; ---------- components: Interpreter Core messages: 77013 nosy: fboule severity: normal status: open title: Long jumps with frame_setlineno type: crash versions: Python 2.5, Python 2.5.3, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 14:19:19 2008 From: report at bugs.python.org (Mark Tolonen) Date: Fri, 05 Dec 2008 13:19:19 +0000 Subject: [issue4485] fast swap of "default" Windows python versions In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za> Message-ID: <1228483159.83.0.0748052868351.issue4485@psf.upfronthosting.co.za> Mark Tolonen added the comment: An extension to this idea: Support parsing #! lines in Windows and select the version of Python used. python.exe could examine: #!/usr/bin/python30 pattern match "python##", look in the registry to see if that version of python is installed, and launch that python.exe instead. ---------- nosy: +metolone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 14:24:01 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 13:24:01 +0000 Subject: [issue4545] doctest seems to always fail on numpy.array2string In-Reply-To: <1228477555.39.0.103154485661.issue4545@psf.upfronthosting.co.za> Message-ID: <1228483441.51.0.674583022322.issue4545@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Doctest output scrupulously follows the output of an interactive session of python. On my machine: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> numpy.array2string(numpy.arange(2)) '[0 1]' >>> The the interactive session does not simply print objects, it calls repr() on them, so that you can make the distinction between the number 0 and the string "0". You should add quotes to your doctest string, or use print: >>> import numpy >>> print numpy.array2string(numpy.arange(2)) [0 1] ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 14:50:07 2008 From: report at bugs.python.org (Muhammad Alkarouri) Date: Fri, 05 Dec 2008 13:50:07 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1228485007.74.0.2704083402.issue4017@psf.upfronthosting.co.za> Muhammad Alkarouri added the comment: Now that Python 2.6.1 is out, can we expect a new OS X installer built correctly? I think this is pretty important.. ---------- nosy: +malkarouri _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:09:08 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 14:09:08 +0000 Subject: [issue4547] Long jumps with frame_setlineno In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za> Message-ID: <1228486148.05.0.842164161179.issue4547@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Attached patch is similar (it declares the variable as "unsigned char*") and adds a test. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc stage: -> patch review Added file: http://bugs.python.org/file12240/frame_setlineno.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:32:28 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2008 14:32:28 +0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1228487548.23.0.212990611144.issue1814@psf.upfronthosting.co.za> STINNER Victor added the comment: After many benchmarks, I realized that it's not a good idea to use GMP for the int (and long) integers because most integers are very small: less or equals than 32 bits (or 64 bits on a 64 bits CPU). GMP overhead is too big. See other propositions to optimize Python integers. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:34:17 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2008 14:34:17 +0000 Subject: [issue4233] open(0, closefd=False) prints 3 warnings In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za> Message-ID: <1228487657.38.0.0666917640965.issue4233@psf.upfronthosting.co.za> STINNER Victor added the comment: 2.6.1 is released. Should this issue be apply to 2.6.x or not? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:41:57 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 14:41:57 +0000 Subject: [issue4546] Small thingy in "What's New in Python 3.0" In-Reply-To: <1228481882.44.0.510834493207.issue4546@psf.upfronthosting.co.za> Message-ID: <1228488117.69.0.733564819621.issue4546@psf.upfronthosting.co.za> Georg Brandl added the comment: This is already fixed in SVN and will be upated with the next rebuild of the docs. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:45:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 14:45:16 +0000 Subject: [issue4517] improve __getattribute__ documentation In-Reply-To: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za> Message-ID: <1228488316.33.0.368140393197.issue4517@psf.upfronthosting.co.za> Georg Brandl added the comment: Isn't what you refer to covered by this paragraph and the following example: "In addition to bypassing any instance attributes in the interest of correctness, implicit special method lookup may also bypass the __getattribute__() method even of the object?s metaclass:"? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:45:33 2008 From: report at bugs.python.org (fboule) Date: Fri, 05 Dec 2008 14:45:33 +0000 Subject: [issue4547] Long jumps with frame_setlineno In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za> Message-ID: <1228488333.98.0.0138673870235.issue4547@psf.upfronthosting.co.za> fboule added the comment: Is it intended to be applied on Python 2.5.x and/or Python 2.6.x (and when)? The current Python 2.6.1 release does not have the fix. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:53:57 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2008 14:53:57 +0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1228488837.06.0.538342308161.issue1814@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:54:41 2008 From: report at bugs.python.org (Laszlo) Date: Fri, 05 Dec 2008 14:54:41 +0000 Subject: [issue4536] SystemError if invalid arguments passed to range() and step=-1 In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za> Message-ID: <1228488881.4.0.683570490885.issue4536@psf.upfronthosting.co.za> Laszlo added the comment: It is changed from PyErr_Clear() to Py_CLEAR(step) because in case someone else makes the same mistake of not checking for an error before calling validate_step() we do not want to hide the error. It is true that if used properly this part will not get executed, but if there is another similar programming error like the patch fixes in range_new() it will at least let the programmer see the right traceback in the terminal. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:06:40 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 05 Dec 2008 15:06:40 +0000 Subject: [issue4336] Fix performance issues in xmlrpclib In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> Message-ID: <1228489600.27.0.481366405261.issue4336@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I think it would have been better to have endheaders() (and then perhaps _send_output()) deal with the non-string (i.e. filebuffer) case, so that endheaders(body) is semantically equivalent to endheaders(); send(body). The version you checked in makes it necessary that the user of HTTPConnection.endheaders() is aware of the distinction. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:06:44 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 15:06:44 +0000 Subject: [issue4547] Long jumps with frame_setlineno In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za> Message-ID: <1228489604.51.0.612585255499.issue4547@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes, target is 2.6.2 and up, 3.0.1 and up. ---------- versions: +Python 3.0 -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:12:36 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 15:12:36 +0000 Subject: [issue4505] ob_size not removed from docs In-Reply-To: <1228320830.04.0.998447040323.issue4505@psf.upfronthosting.co.za> Message-ID: <1228489956.31.0.478426659381.issue4505@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67578. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:12:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 15:12:42 +0000 Subject: [issue4504] Doc/includes out of date In-Reply-To: <1228317151.0.0.247263497976.issue4504@psf.upfronthosting.co.za> Message-ID: <1228489962.83.0.529900011701.issue4504@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67578. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:19:32 2008 From: report at bugs.python.org (Olivier Hervieu) Date: Fri, 05 Dec 2008 15:19:32 +0000 Subject: [issue4548] OptionParser : Weird comportement in args processing In-Reply-To: <1228490372.76.0.909413674662.issue4548@psf.upfronthosting.co.za> Message-ID: <1228490372.76.0.909413674662.issue4548@psf.upfronthosting.co.za> New submission from Olivier Hervieu : Hi guys.. i found something strange on the behavior of OptionParser If I have this sample code : import sys from optparse import OptionParser if __name__ == '__main__': parser = OptionParser() parser.add_option("-p", "--p", help="The P of python", default=None) parser.add_option("-y", "--y", help="The Y of python", default=None) (options,args) = parser.parse_args(sys.argv) print options and i execute : myFile.py -p -y the options.p will be -y and options.y will be None worst.. if my user say : myFile.py -p -y 'thon' options.p will be -y and options.y will be None... In all case I think that, if i do myFile.py -p -y options -p and options -y must be None and if i want to put -y in options.p i say something like myFile.py -p "-y" so i can do after myFile.py -p "-y" -y "thon". ---------- components: Extension Modules messages: 77028 nosy: ohervieu severity: normal status: open title: OptionParser : Weird comportement in args processing type: behavior versions: Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:21:39 2008 From: report at bugs.python.org (David W. Lambert) Date: Fri, 05 Dec 2008 15:21:39 +0000 Subject: [issue4517] improve __getattribute__ documentation In-Reply-To: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za> Message-ID: <1228490499.55.0.145216521207.issue4517@psf.upfronthosting.co.za> David W. Lambert added the comment: Yes to msg77021. However! I'll pin the difficulty specifically to the word "may". This cost me a lot of time. 1) Please change the phrasing you quoted to "... implicit special method lookup bypasses the __getattribute__() method even of the object?s metaclass:" 2) Please insert into the glossary a definition of "implicit special method lookup" that addresses the grammar or syntax that causes it considering monad and dyad use. Thank you. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:29:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 15:29:45 +0000 Subject: [issue4517] improve __getattribute__ documentation In-Reply-To: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za> Message-ID: <1228490985.42.0.892298165788.issue4517@psf.upfronthosting.co.za> Georg Brandl added the comment: I've changed "may bypass" to "generally bypasses". It doesn't happen for all methods, but that's an implementation detail. I've also added a glossary entry "special method" in r67579. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:30:58 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 15:30:58 +0000 Subject: [issue4511] Decorators should have an index entry In-Reply-To: <1228350514.36.0.487340593327.issue4511@psf.upfronthosting.co.za> Message-ID: <1228491058.92.0.675710973214.issue4511@psf.upfronthosting.co.za> Georg Brandl added the comment: In the 2.6 and 3.0 docs, decorators do have an index entry, see http://docs.python.org/genindex-D.html. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:34:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 15:34:02 +0000 Subject: [issue4478] shutil.copyfile documentation In-Reply-To: <1228106318.66.0.677132442112.issue4478@psf.upfronthosting.co.za> Message-ID: <1228491242.62.0.829041181856.issue4478@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67580. If we want to start using things like :raises:, it will have to be in some coordinated fashion so that it doesn't occur in isolated places. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:37:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 15:37:53 +0000 Subject: [issue4548] OptionParser : Weird comportement in args processing In-Reply-To: <1228490372.76.0.909413674662.issue4548@psf.upfronthosting.co.za> Message-ID: <1228491473.05.0.766409609989.issue4548@psf.upfronthosting.co.za> Georg Brandl added the comment: This is not a bug. By default, options in optparse take an argument -- therefore, the -y is taken as the argument to the -p option. Use e.g. add_option(..., action='store_true') to specify an option that doesn't take an argument. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:42:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 15:42:22 +0000 Subject: [issue3171] operator.*slice() should be deprecated in 2.6 In-Reply-To: <1214113899.38.0.968396659077.issue3171@psf.upfronthosting.co.za> Message-ID: <1228491742.34.0.22131127062.issue3171@psf.upfronthosting.co.za> Georg Brandl added the comment: Documented as deprecated in r67581. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:54:19 2008 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 05 Dec 2008 15:54:19 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <1228475918.39.0.85384130998.issue4506@psf.upfronthosting.co.za> Message-ID: <18745.20125.849667.485095@montanaro-dyndns-org.local> Skip Montanaro added the comment: Mark> 1. What happens if you build with the '-ffloat-store' option to Mark> gcc? Doesn't quite work: % ./python Python 3.0 (r30:67503, Dec 5 2008, 09:48:42) [GCC 4.2.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cmath >>> cmath.exp(complex(710.0, 1.5)) Segmentation Fault (core dumped) :-/ Mark> 2. It looks as though the configure script isn't finding 'isinf' Mark> on Solaris 10. Any ideas why? Is there some replacement for Mark> isinf that's spelt differently? I suspect that if we were Mark> using the system lib's test for infinity instead of the Mark> Py_IS_INFINITY workaround then this problem wouldn't have come Mark> up. Thanks for the tip. The configure script doesn't #include so isinf() is not mapped to __builtin_isinf(). Consequently the conftest link fails: configure:21401: checking for isinf configure:21457: gcc -o conftest -g -O2 conftest.c -lresolv -lsocket -lnsl -lrt -ldl -lm >&5 conftest.c:252: warning: conflicting types for built-in function 'isinf' Undefined first referenced symbol in file isinf /var/tmp//ccmTAet6.o ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status I found this code in /usr/include/iso/math_c99.h, included by : #undef isinf #define isinf(x) __builtin_isinf(x) Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:31:14 2008 From: report at bugs.python.org (ZX) Date: Fri, 05 Dec 2008 16:31:14 +0000 Subject: [issue4549] A defect in - (Python3.0) In-Reply-To: <1228494674.65.0.590088285872.issue4549@psf.upfronthosting.co.za> Message-ID: <1228494674.65.0.590088285872.issue4549@psf.upfronthosting.co.za> New submission from ZX : "If a name is declared global, then all references and assignments go directly to the middle scope containing the module?s global names. Otherwise, all variables found outside of the innermost scope are read-only (an attempt to write to such a variable will simply create a new local variable in the innermost scope, leaving the identically named outer variable unchanged)." ___excerpt from -- The above description is correct in Python 2.X. Since 3.X introduced the "nonlocal" keyword, I think the above description is obsolete, need to be upgraded. ---------- assignee: georg.brandl components: Documentation messages: 77036 nosy: PyTiger, georg.brandl severity: normal status: open title: A defect in - (Python3.0) versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:43:45 2008 From: report at bugs.python.org (Chris AtLee) Date: Fri, 05 Dec 2008 16:43:45 +0000 Subject: [issue3243] Support iterable bodies in httplib In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za> Message-ID: <1228495425.95.0.445374616515.issue3243@psf.upfronthosting.co.za> Chris AtLee added the comment: The attached patch implements this for python 2.7. It also adds support for iterable bodies in urllib2, where it is more generally useful. urllib2 enforces the presence of a Content-Length header in the request if the body is an iterable, whereas httplib does not. The patch also includes updates to docs and tests (which all pass as of r67584 on my macbook) ---------- keywords: +patch Added file: http://bugs.python.org/file12241/python-3243.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:03:57 2008 From: report at bugs.python.org (Kandalintsev Alexandre) Date: Fri, 05 Dec 2008 17:03:57 +0000 Subject: [issue4535] Build / Test Py3K failed on Ubuntu 8.10 In-Reply-To: <1228423046.58.0.110673745829.issue4535@psf.upfronthosting.co.za> Message-ID: <1228496637.25.0.871683428311.issue4535@psf.upfronthosting.co.za> Kandalintsev Alexandre added the comment: My results on ubuntu 8.10 x86(with debug features enabled) on Python 3.1a0 (py3k:67586, Dec 5 2008, 19:39:50): 298 tests OK. 23 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu test_dbm_ndbm test_kqueue test_nis test_normalization test_ossaudiodev test_pep277 test_socketserver test_startfile test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 3 skips unexpected on linux2: test_tcl test_dbm_ndbm test_dbm_gnu [870063 refs] May be problems fixed in current trunk(http://svn.python.org/projects/ python/branches/py3k)? ---------- nosy: +exe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:04:21 2008 From: report at bugs.python.org (K. C. Wong) Date: Fri, 05 Dec 2008 17:04:21 +0000 Subject: [issue4511] Decorators should have an index entry In-Reply-To: <1228350514.36.0.487340593327.issue4511@psf.upfronthosting.co.za> Message-ID: <1228496661.06.0.0656213522351.issue4511@psf.upfronthosting.co.za> K. C. Wong added the comment: My mistake for including 2.6. While having a link to an entry in the Glossary is a huge improvement, it comes about as a result of the index now covering all components of the Python documentation. I feel at the least, there should be a link within the glossary entry back to the appropriate sections in the Language Reference. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:09:32 2008 From: report at bugs.python.org (Jerry Chen) Date: Fri, 05 Dec 2008 17:09:32 +0000 Subject: [issue4550] Deprecated python 2.x syntax in "HOWTO Use Python in the web" In-Reply-To: <1228496972.39.0.491433702002.issue4550@psf.upfronthosting.co.za> Message-ID: <1228496972.39.0.491433702002.issue4550@psf.upfronthosting.co.za> New submission from Jerry Chen : For people who are following HOWTO guides verbatim, there are two types of Python 2.x'isms in "HOWTO Use Python in the web" (http://www.python.org/doc/3.0/howto/webservers.html): 1. ``print`` statements instead of functions. 2. Use of beloved but deprecated ``%`` format operator. Please see attached patch for the ReST source found at http://www.python.org/doc/3.0/_sources/howto/webservers.txt. Note: ``2to3`` was not actually used, as the filename may suggest. ---------- assignee: georg.brandl components: Documentation files: webservers-2to3.patch keywords: patch messages: 77040 nosy: georg.brandl, jcsalterego severity: normal status: open title: Deprecated python 2.x syntax in "HOWTO Use Python in the web" versions: Python 3.0 Added file: http://bugs.python.org/file12242/webservers-2to3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:27:47 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 17:27:47 +0000 Subject: [issue4497] Compiler warnings in longobject.c In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> Message-ID: <1228498067.08.0.428281224318.issue4497@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed in r67588 (py3k), r65789 (release30-maint). None of the fixes apply to 2.x. ---------- resolution: -> fixed status: open -> closed versions: -Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:31:01 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 17:31:01 +0000 Subject: [issue4497] Compiler warnings in longobject.c In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za> Message-ID: <1228498261.25.0.141500418546.issue4497@psf.upfronthosting.co.za> Mark Dickinson added the comment: > r65789 That should be r67589. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:36:22 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 17:36:22 +0000 Subject: [issue4507] 3.0 test failure on Mac OS X 10.5.5 In-Reply-To: <18742.63130.521395.761295@montanaro-dyndns-org.local> Message-ID: <1228498582.58.0.772385870065.issue4507@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing as duplicate. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:37:56 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 17:37:56 +0000 Subject: [issue965036] Fix for #777597 - socketmodule.c connection handling incorec Message-ID: <1228498676.03.0.987402703148.issue965036@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: A similar patch was applied 4 years ago, in r36739. ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:51:38 2008 From: report at bugs.python.org (Adam Olsen) Date: Fri, 05 Dec 2008 17:51:38 +0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1228499498.74.0.417113656606.issue1215@psf.upfronthosting.co.za> Adam Olsen added the comment: I'm in favour of just the doc change now. It's less work and we don't really need to disable that usage. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:52:11 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 17:52:11 +0000 Subject: [issue928332] Python interpreter stalled on _PyPclose.WaitForSingleObject Message-ID: <1228499531.67.0.320894341597.issue928332@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: os.popen is now deprecated; the subprocess module does all this much better. ---------- nosy: +amaury.forgeotdarc resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:55:30 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Dec 2008 17:55:30 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1228499730.65.0.607233400462.issue826897@psf.upfronthosting.co.za> Terry J. Reedy added the comment: James Stroud ran into this same issue with 2.5. Here is his 'ugly fix' for working with protocol 2 only. class DictPlus(dict): def __init__(self, *args, **kwargs): self.extra_thing = ExtraThingClass() dict.__init__(self, *args, **kwargs) def __setitem__(self, k, v): try: do_something_with(self.extra_thing, k, v) except AttributeError: self.extra_thing = ExtraThingClass() do_something_with(self.extra_thing, k, v) dict.__setitem__(self, k, v) def __setstate__(self, adict): pass Can this be closed as "won't fix", since there seems nothing to fix? This issue of working with all protocols would seem dead by now, and for protocol 2, it is a 'gotcha' that can be avoided with knowledge. ---------- nosy: +tjreedy versions: +Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:00:23 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 18:00:23 +0000 Subject: [issue4511] Decorators should have an index entry In-Reply-To: <1228350514.36.0.487340593327.issue4511@psf.upfronthosting.co.za> Message-ID: <1228500023.22.0.519148852675.issue4511@psf.upfronthosting.co.za> Georg Brandl added the comment: OK, I've added a back-link in r67591. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:04:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 18:04:48 +0000 Subject: [issue4550] Deprecated python 2.x syntax in "HOWTO Use Python in the web" In-Reply-To: <1228496972.39.0.491433702002.issue4550@psf.upfronthosting.co.za> Message-ID: <1228500288.62.0.120222668457.issue4550@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67593. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:07:28 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 18:07:28 +0000 Subject: [issue4549] A defect in - (Python3.0) In-Reply-To: <1228494674.65.0.590088285872.issue4549@psf.upfronthosting.co.za> Message-ID: <1228500448.39.0.664262886447.issue4549@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for reporting, there was already a comment in the source about this :) Fixed in r67594. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:22:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 18:22:26 +0000 Subject: [issue4457] __import__ documentation obsolete In-Reply-To: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za> Message-ID: <1228501346.7.0.24090354585.issue4457@psf.upfronthosting.co.za> Georg Brandl added the comment: Attached is a proposed rewrite of the __import__ documentation. ---------- keywords: +patch Added file: http://bugs.python.org/file12243/import-docs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:25:24 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Fri, 05 Dec 2008 18:25:24 +0000 Subject: [issue4457] __import__ documentation obsolete In-Reply-To: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za> Message-ID: <1228501524.26.0.783332921482.issue4457@psf.upfronthosting.co.za> Mart S?mermaa added the comment: Brett, don't you think the >>> import sys >>> __import__('x.y.z') >>> mod = sys.modules['x.y.z'] idiom should be recommended instead of/additionally to the lengthy getattr() one? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:45:38 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 18:45:38 +0000 Subject: [issue1030250] distutils' dry-run wants to create some real build dirs Message-ID: <1228502738.12.0.56048312939.issue1030250@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The third parameter to mkpath() is 'verbose', not 'dry_run'! Correction is trivial: Index: Lib/distutils/ccompiler.py =================================================================== --- Lib/distutils/ccompiler.py (revision 67068) +++ Lib/distutils/ccompiler.py (working copy) @@ -1041,7 +1041,7 @@ return move_file (src, dst, dry_run=self.dry_run) def mkpath (self, name, mode=0777): - mkpath (name, mode, self.dry_run) + mkpath (name, mode, dry_run=self.dry_run) # class CCompiler ---------- assignee: -> amaury.forgeotdarc keywords: +patch nosy: +amaury.forgeotdarc stage: -> patch review versions: +Python 2.6, Python 3.0 -Python 2.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:56:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Dec 2008 18:56:35 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228503395.53.0.559991519771.issue4509@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Please see patch at http://codereview.appspot.com/10049 ---------- keywords: +needs review, patch stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:19:46 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Dec 2008 19:19:46 +0000 Subject: [issue4481] Windows installer crash In-Reply-To: <1228146345.67.0.732952109448.issue4481@psf.upfronthosting.co.za> Message-ID: <1228504786.2.0.957488367514.issue4481@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, just as one uses the x86 installer for 32-bit amd chips, like mine ;-) ---------- nosy: +tjreedy resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:20:03 2008 From: report at bugs.python.org (Brett Cannon) Date: Fri, 05 Dec 2008 19:20:03 +0000 Subject: [issue4457] __import__ documentation obsolete In-Reply-To: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za> Message-ID: <1228504803.46.0.319261384548.issue4457@psf.upfronthosting.co.za> Brett Cannon added the comment: Yes, the simple __import__/sys.modules idiom should be the suggested idiom until a proper function is provided in the standard library. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:25:14 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 19:25:14 +0000 Subject: [issue4510] ValueError for list.remove() not very helpful In-Reply-To: <1228347518.63.0.0108612017272.issue4510@psf.upfronthosting.co.za> Message-ID: <1228505114.42.0.893210571818.issue4510@psf.upfronthosting.co.za> Georg Brandl added the comment: Suggested patch attached, handles remove() and index(). ---------- keywords: +patch nosy: +georg.brandl stage: needs patch -> patch review Added file: http://bugs.python.org/file12244/list-excs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:25:57 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 19:25:57 +0000 Subject: [issue4244] ihooks incompatible with absolute_import feature In-Reply-To: <1225459960.12.0.259014417715.issue4244@psf.upfronthosting.co.za> Message-ID: <1228505157.63.0.586725929022.issue4244@psf.upfronthosting.co.za> Georg Brandl added the comment: ihooks is undocumented and deprecated, so I doubt anything will be done about that. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:28:39 2008 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 05 Dec 2008 19:28:39 +0000 Subject: [issue4485] fast swap of "default" Windows python versions In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za> Message-ID: <1228505319.91.0.704735205245.issue4485@psf.upfronthosting.co.za> Glenn Linderman added the comment: Since Python hasn't done that until now, it won't help much with the transition from 2to3. The earliest versions that could add that would be 3.1 and 2.7, it would seem, as it is a new fetaure. Perhaps it would be worth doing, in planning for Python 4... Perl has done that for many versions. The idea is useful for running scripts that were designed and tested with a given version of Perl, on that same version, to avoid the need to retest working, production, code. Even when compatibility is supposed to be retained, and every effort is made to do so in a maintenance release, sometimes little things sneak in, that no one ever thought to test, and didn't to have broken... so continuing to use the version with which a production script was last extensively tested with, is "extra safe". The technique you suggest isn't very good for testing a particular script with various versions of python because you'd have to edit the script to select the version. It is good for being "extra safe" and ensuring that a script continues to run with a particular version of the interpreter. I see this issue addressing the ability, in a testing environment, to swap what version of implicit python is invoked for scripts invoked from either the command line or from batch files, without the need to edit the script or the batch file. From the command line, it is relatively easy just to invoke the right python via "c:\pythonNN\python script", although that gets old if you are testing a large number of scripts. So I see it as primarily a convenience item for a testing environment. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:31:32 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 19:31:32 +0000 Subject: [issue4461] parameters of PyLong_FromString() are not checked for NULL In-Reply-To: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za> Message-ID: <1228505492.71.0.420446176242.issue4461@psf.upfronthosting.co.za> Mark Dickinson added the comment: All tests pass with this patch. Committed to trunk, r67590. Will merge to 2.7, 3.0 and 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:32:29 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 19:32:29 +0000 Subject: [issue4461] parameters of PyLong_FromString() are not checked for NULL In-Reply-To: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za> Message-ID: <1228505549.41.0.255061424611.issue4461@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: -Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:41:43 2008 From: report at bugs.python.org (Andreas Kupries) Date: Fri, 05 Dec 2008 19:41:43 +0000 Subject: [issue4551] The python 2.6.1 source distribution is missing Doc/tools/sphinxext In-Reply-To: <1228506103.58.0.313450580338.issue4551@psf.upfronthosting.co.za> Message-ID: <1228506103.58.0.313450580338.issue4551@psf.upfronthosting.co.za> New submission from Andreas Kupries : The directory Doc/tools/sphinxext is missing in the Python 2.6.1 source distribution. This breaks building the html help. The directory is present in the Python 2.6 source distribution. ---------- components: Installation messages: 77061 nosy: andreask severity: normal status: open title: The python 2.6.1 source distribution is missing Doc/tools/sphinxext versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:56:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 05 Dec 2008 19:56:54 +0000 Subject: [issue4551] The python 2.6.1 source distribution is missing Doc/tools/sphinxext In-Reply-To: <1228506103.58.0.313450580338.issue4551@psf.upfronthosting.co.za> Message-ID: <1228507014.5.0.390135173322.issue4551@psf.upfronthosting.co.za> Georg Brandl added the comment: This was caused by a bug in the release script. Fixed in r67599. Thanks for the report! ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:03:29 2008 From: report at bugs.python.org (Felix Benner) Date: Fri, 05 Dec 2008 20:03:29 +0000 Subject: [issue4522] Module wsgiref is not python3000 ready (unicode issues) In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za> Message-ID: <1228507409.96.0.026489800548.issue4522@psf.upfronthosting.co.za> Felix Benner added the comment: The test uses StringIO. I don't understand the test enough to change that. If I understand the WSGI spec correctly then it would be the test that's wrong. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:35:56 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 05 Dec 2008 20:35:56 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1228509356.61.0.471009597074.issue826897@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:36:18 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 05 Dec 2008 20:36:18 +0000 Subject: [issue1030250] distutils' dry-run wants to create some real build dirs Message-ID: <1228509378.01.0.977124337351.issue1030250@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Looks good. ---------- nosy: +lemburg stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:51:28 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 05 Dec 2008 20:51:28 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228480089.15.0.0706302083901.issue4540@psf.upfronthosting.co.za> Message-ID: <4939944C.3080809@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-05 13:28, Amaury Forgeot d'Arc wrote: > Amaury Forgeot d'Arc added the comment: > > Attached patch ignores any Exception during module import. > Note that KeyboardInterrupt is not caught: it is not an Exception. Is there a reason why "formatter" is imported inside the method rather than at module scope ? Other than that the patch looks good. > I could provide a similar patch for 2.7, if there is some interest; but > no crash was reported. Python 2.6 and 2.7 have the same problem: help> modules web Here is a list of matching modules. Enter any module name to get more help. ... Traceback (most recent call last): File "", line 1, in File "/usr/local/python-2.6-ucs2/lib/python2.6/site.py", line 429, in __call__ return pydoc.help(*args, **kwds) File "/usr/local/python-2.6-ucs2/lib/python2.6/pydoc.py", line 1687, in __call__ self.interact() File "/usr/local/python-2.6-ucs2/lib/python2.6/pydoc.py", line 1705, in interact self.help(request) File "/usr/local/python-2.6-ucs2/lib/python2.6/pydoc.py", line 1723, in help self.listmodules(split(request)[1]) File "/usr/local/python-2.6-ucs2/lib/python2.6/pydoc.py", line 1812, in listmodules apropos(key) File "/usr/local/python-2.6-ucs2/lib/python2.6/pydoc.py", line 1912, in apropos ModuleScanner().run(callback, key) File "/usr/local/python-2.6-ucs2/lib/python2.6/pydoc.py", line 1877, in run for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror): File "/usr/local/python-2.6-ucs2/lib/python2.6/pkgutil.py", line 110, in walk_packages __import__(name) File "/home/lemburg/lib/DNS/__init__.py", line 13, in import Type,Opcode,Status,Class File "/home/lemburg/lib/DNS/Type.py", line 67 SyntaxError: Non-ASCII character '\xf6' in file /home/lemburg/lib/DNS/Type.py on line 67, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details (pydoc will look in all modules on sys.path, so chances are high that users will run into similar problems) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:54:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 20:54:37 +0000 Subject: [issue4461] parameters of PyLong_FromString() are not checked for NULL In-Reply-To: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za> Message-ID: <1228510477.13.0.982763778238.issue4461@psf.upfronthosting.co.za> Mark Dickinson added the comment: Merged. Thanks for the report, Brian. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:55:35 2008 From: report at bugs.python.org (Matthias Klose) Date: Fri, 05 Dec 2008 20:55:35 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> New submission from Matthias Klose : Doc/tools/sphinxext not included in the 2.6.1 tarball, but it is checked in. ---------- components: Build messages: 77067 nosy: doko priority: deferred blocker severity: normal status: open title: Doc/tools/sphinxext not included in the 2.6.1 tarball versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:59:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 05 Dec 2008 20:59:27 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228510767.25.0.208260325683.issue4552@psf.upfronthosting.co.za> Christian Heimes added the comment: Does it also affect Python 3.0? ---------- assignee: -> barry nosy: +barry, christian.heimes stage: -> test needed type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:04:47 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 21:04:47 +0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1228511087.85.0.636512519259.issue1814@psf.upfronthosting.co.za> Mark Dickinson added the comment: I agree that this probably isn't right for core Python. But I think this is valuable work, and it would be nice to see this patch available and maintained somewhere, if anyone has the energy. I'm wondering whether the Sage folks would be interested in this; as I understand it, they currently have Python integers *and* Sage integers (based on GMP), along with various rules about which integers you can use for what. For example, according to http://www.sagemath.org/doc/prog/node21.html you can't use a Sage integer as a list index. Having just one type of integer might simplify things a little. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:17:28 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 05 Dec 2008 21:17:28 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228511848.62.0.252956310955.issue4552@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Wait, should Doc/tools/sphinxext be included in the source tarball or not? I thought it was a documentation build artifact. If so, then we need to clean out the pycs it contains in a different way. In any case, the 3.0 tarballs should include sphinxext for better or worse, because this directory is removed by the release.py script. However, the removal of it was not added to release.py until after the 3.0 tarballs were made (the 2.6.1 tarballs do not include sphinxext). Tell me which it should be and I'll fix release.py ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:19:44 2008 From: report at bugs.python.org (Mark Tolonen) Date: Fri, 05 Dec 2008 21:19:44 +0000 Subject: [issue4485] fast swap of "default" Windows python versions In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za> Message-ID: <1228511984.5.0.436445775641.issue4485@psf.upfronthosting.co.za> Mark Tolonen added the comment: I see it as primarily useful in this transition period between 2.x and 3.0, since py3 scripts aren't backward compatible and I see both being installed for the few years. It could be a front-end launcher suitable for "ftype Python.File" that inspects the script for #! and checks the registry for installed python versions. That would make it work with older versions as well. Probably better suited to discussion on c.l.p than here, but at least recorded as an idea in this feature request. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:20:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 05 Dec 2008 21:20:34 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228512034.25.0.110552328078.issue4552@psf.upfronthosting.co.za> Christian Heimes added the comment: In my opinion the tar balls should contain all necessary bits and pieces to build the docs yourself. It makes no sense to include the Doc/ folder w/o any means to use them. Let's include sphinxext and document the required versions of sphinx, docutils and jinja. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:32:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 21:32:59 +0000 Subject: [issue2937] Incorrect rounding in floating-point operations with gcc/x87 In-Reply-To: <1211402217.78.0.330998218554.issue2937@psf.upfronthosting.co.za> Message-ID: <1228512779.24.0.620001377237.issue2937@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing as invalid. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:35:44 2008 From: report at bugs.python.org (Leger) Date: Fri, 05 Dec 2008 21:35:44 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228512944.58.0.422748806484.issue4483@psf.upfronthosting.co.za> Leger added the comment: This patch resolve the problem. Evidence with "make test" : ... test_dbm test_dbm_dumb test_dbm_gnu test_dbm_ndbm ... Many thanks Skip. You can close this bug I think. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:43:21 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 21:43:21 +0000 Subject: [issue3366] Add gamma function, error functions and other C99 math.h functions to math module In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za> Message-ID: <1228513401.37.0.895574236829.issue3366@psf.upfronthosting.co.za> Mark Dickinson added the comment: There have been requests to add other C99 libm functions to Python: expm1 is requested in issue 3501, and log2 came up in the issue 3724 discussion. I'm absorbing those issues into this one. With these two, and the gamma and error functions, we're pretty close to implementing all the functions in C99s math.h. Seems to me that we might as well aim for completeness and implement the whole lot. ---------- title: Add gamma and error functions to math module -> Add gamma function, error functions and other C99 math.h functions to math module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:44:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 21:44:59 +0000 Subject: [issue3501] expm1 missing In-Reply-To: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za> Message-ID: <1228513499.39.0.468775558262.issue3501@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm absorbing this issue into issue 3366. ---------- resolution: -> duplicate status: open -> closed superseder: -> Add gamma function, error functions and other C99 math.h functions to math module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:47:35 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 21:47:35 +0000 Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x) In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za> Message-ID: <1228513655.85.0.0950277451032.issue3724@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm closing this, for reasons already given. For the proposal to add log2, see issue 3366. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:49:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 21:49:58 +0000 Subject: [issue2110] Implement __format__ for Decimal In-Reply-To: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za> Message-ID: <1228513798.14.0.094146080512.issue2110@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- priority: -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:56:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 05 Dec 2008 21:56:59 +0000 Subject: [issue4445] String allocations waste 3 bytes of memory on average. In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za> Message-ID: <1228514219.58.0.782637427071.issue4445@psf.upfronthosting.co.za> Mark Dickinson added the comment: Applied to the trunk in r67601. Will merge to other branches if the buildbots look okay. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:12:33 2008 From: report at bugs.python.org (Nicholas Patterson) Date: Fri, 05 Dec 2008 22:12:33 +0000 Subject: [issue4553] Results from os.path.islink and os.stat S_ISLNK do not match In-Reply-To: <1228515153.01.0.915897316596.issue4553@psf.upfronthosting.co.za> Message-ID: <1228515153.01.0.915897316596.issue4553@psf.upfronthosting.co.za> New submission from Nicholas Patterson : See attached file, os.path.islink correctly identifies symlinks as symlinks, but S_ISLNK is not reporting them as such. ---------- components: None files: demo.txt messages: 77079 nosy: npatters severity: normal status: open title: Results from os.path.islink and os.stat S_ISLNK do not match type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file12245/demo.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:14:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 05 Dec 2008 22:14:13 +0000 Subject: [issue4553] Results from os.path.islink and os.stat S_ISLNK do not match In-Reply-To: <1228515153.01.0.915897316596.issue4553@psf.upfronthosting.co.za> Message-ID: <1228515253.12.0.81300931862.issue4553@psf.upfronthosting.co.za> Christian Heimes added the comment: The behavior is correct. You want os.lstat, not os.stat. http://docs.python.org/library/os.html#os.lstat ---------- nosy: +christian.heimes resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:14:14 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Dec 2008 22:14:14 +0000 Subject: [issue4488] Python Documentation not Newb Friendly In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> Message-ID: <1228515254.35.0.788908852283.issue4488@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, the new docs are much better. Methods are nicely identified in 2.6/3.0 docs that I checked. There is one category that is not: constants. For instance, the following is from the subprocess doc. "stdin, stdout and stderr specify the executed programs? standard input, standard output and standard error file handles, respectively. Valid values are PIPE, an existing file descriptor (a positive integer), an existing file object, and None. PIPE indicates that a new pipe to the child should be created. With None, no redirection will occur; the child?s file handles will be inherited from the parent. Additionally, stderr can be STDOUT, which indicates that the stderr data from the applications should be captured into the same file handle as for stdout." As I discovered, neither 'PIPE' nor PIPE is valid, subprocess.PIPE is what is required. (Ditto for subprocess.STDOUT I presume.) Can such names of constants be fully qualified just as method names are now? ---------- nosy: +tjreedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:20:32 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 22:20:32 +0000 Subject: [issue4522] Module wsgiref is not python3000 ready (unicode issues) In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za> Message-ID: <1228515632.75.0.40728074715.issue4522@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The test should indeed be changed. You may want to use io.BytesIO instead. In any case this test looks like a standard usage of the library. Please make it as pleasant-looking as possible. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:21:12 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 22:21:12 +0000 Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za> Message-ID: <1228515672.53.0.222839882291.issue4537@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Merged the 2nd fix with r67602. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:22:30 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2008 22:22:30 +0000 Subject: [issue4540] typo in a module describes utf-8 as uft-8 In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za> Message-ID: <1228515750.21.0.30486227247.issue4540@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- assignee: -> amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:50:10 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Fri, 05 Dec 2008 22:50:10 +0000 Subject: [issue1569356] sys.settrace cause curried parms to show up as attributes Message-ID: <1228517410.39.0.344958634667.issue1569356@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: It would be great if this could be backported. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 00:56:13 2008 From: report at bugs.python.org (Martin Diers) Date: Fri, 05 Dec 2008 23:56:13 +0000 Subject: [issue4528] test_httpservers consistently fails on OS X In-Reply-To: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za> Message-ID: <1228521373.88.0.85139005006.issue4528@psf.upfronthosting.co.za> Martin Diers added the comment: A couple more notes: I am building using a fink installation: --prefix=/sw, in order to gain readline support. The only modules that are not installed are ossaudiodev and spwd. Next, I just did a build from a checkout of the r30 tag on svn. Before, I built from the release tarball. The build from the r30 checkout passed all tests. The build from the python-3.0 tarball fails on test_httpservers. Evidently there is a difference between the r30 tag, and the tarball. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 00:56:17 2008 From: report at bugs.python.org (Martin Diers) Date: Fri, 05 Dec 2008 23:56:17 +0000 Subject: [issue4528] test_httpservers consistently fails on OS X In-Reply-To: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za> Message-ID: <1228521377.39.0.507042777229.issue4528@psf.upfronthosting.co.za> Martin Diers added the comment: A couple more notes: I am building using a fink installation: --prefix=/sw, in order to gain readline support. The only modules that are not installed are ossaudiodev and spwd. Next, I just did a build from a checkout of the r30 tag on svn. Before, I built from the release tarball. The build from the r30 checkout passed all tests. The build from the python-3.0 tarball fails on test_httpservers. Evidently there is a difference between the r30 tag, and the tarball. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 01:06:15 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 06 Dec 2008 00:06:15 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228521975.13.0.475804349251.issue4552@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a duplicate of issue 4551 I do *not* think that Doc/tools should include a complete sphinx checkout; doing "make checkout" is completely acceptable for anybody who wants to build the doc. However, sphinxext is different; this was fixed in r67599 ---------- nosy: +loewis resolution: -> duplicate status: open -> closed superseder: -> The python 2.6.1 source distribution is missing Doc/tools/sphinxext _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 01:41:36 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 06 Dec 2008 00:41:36 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228524096.83.0.735227224433.issue4335@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 01:54:49 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 06 Dec 2008 00:54:49 +0000 Subject: [issue4426] UTF7 decoding is far too strict In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za> Message-ID: <1228524889.46.0.793317185249.issue4426@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:04:22 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 01:04:22 +0000 Subject: [issue4554] Missing make altframeworkinstall for Mac OS X In-Reply-To: <1228525462.29.0.299893265835.issue4554@psf.upfronthosting.co.za> Message-ID: <1228525462.29.0.299893265835.issue4554@psf.upfronthosting.co.za> New submission from Christian Heimes : From http://farmdev.com/thoughts/66/python-3-0-on-mac-os-x-alongside-2-6-2-5-etc-/ $ sudo make frameworkinstall But ... you're not done. There isn't an altframeworkinstall target so you will be overwriting your default python binary. I suggest that an altframeworkinstall target should be added. ---------- components: Installation, Macintosh messages: 77088 nosy: christian.heimes priority: high severity: normal stage: test needed status: open title: Missing make altframeworkinstall for Mac OS X type: feature request versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:22:55 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 06 Dec 2008 01:22:55 +0000 Subject: [issue4199] add shorthand global and nonlocal statements In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za> Message-ID: <1228526575.76.0.135599778024.issue4199@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Please review. ---------- keywords: +needs review stage: -> patch review type: -> feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:29:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 01:29:10 +0000 Subject: [issue4555] Smelly exports In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> Message-ID: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> New submission from Christian Heimes : I just found about the smelly build target. It checks for smelly exports. $ make smelly [...] nm -p libpython2.6.a | \ sed -n "/ [TDB] /s/.* //p" | grep -v "^_*Py" | sort -u; \ asdl_int_seq_new asdl_seq_new init_ast init_codecs initerrno initgc initimp initposix initpwd initsignal init_sre init_symtable initthread initxxsubtype initzipimport nm -p libpython3.0.a | \ sed -n "/ [TDB] /s/.* //p" | grep -v "^_*Py" | sort -u; \ _add_one_to_index_C _add_one_to_index_F asdl_int_seq_new asdl_seq_new These should be checked and fixed. ---------- components: Interpreter Core messages: 77090 nosy: christian.heimes priority: high severity: normal stage: test needed status: open title: Smelly exports type: resource usage versions: Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:38:31 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 06 Dec 2008 01:38:31 +0000 Subject: [issue4555] Smelly exports In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> Message-ID: <1228527511.13.0.905615861919.issue4555@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Are you suggesting that the init* functions in Python 2.6 should not longer be exported? Why? And how? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:57:35 2008 From: report at bugs.python.org (jeff deifik) Date: Sat, 06 Dec 2008 01:57:35 +0000 Subject: [issue4534] problem with str.join - should work with list input, error says requires 'str' object In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za> Message-ID: <1228528655.87.0.991704456014.issue4534@psf.upfronthosting.co.za> jeff deifik added the comment: I fixed the code as follows: return str.join('',lis) I think it is readable, and I understand it. Thanks everyone for clarifying everything _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:58:02 2008 From: report at bugs.python.org (Mike Watkins) Date: Sat, 06 Dec 2008 01:58:02 +0000 Subject: [issue4556] cmp() function erroneously noted as gone in "What's New" In-Reply-To: <1228528682.39.0.573308363833.issue4556@psf.upfronthosting.co.za> Message-ID: <1228528682.39.0.573308363833.issue4556@psf.upfronthosting.co.za> New submission from Mike Watkins : What's new in 3.0 documentation says cmp() function is gone, yet it isn't: >>> sys.version_info; cmp(1,1); cmp(1,2); cmp(2,1) (3, 0, 0, 'final', 0) 0 -1 1 ---------- assignee: georg.brandl components: Documentation messages: 77093 nosy: georg.brandl, mwatkins severity: normal status: open title: cmp() function erroneously noted as gone in "What's New" versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 03:02:35 2008 From: report at bugs.python.org (jeff deifik) Date: Sat, 06 Dec 2008 02:02:35 +0000 Subject: [issue4557] array('c') in python 3.0 produces error, doc says it is ok In-Reply-To: <1228528955.11.0.946708107115.issue4557@psf.upfronthosting.co.za> Message-ID: <1228528955.11.0.946708107115.issue4557@psf.upfronthosting.co.za> New submission from jeff deifik : def char_sieve(): char_data = array('c') ... produces: File ".../prime.py", line 78, in char_sieve char_data = array('c') ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d) However, http://docs.python.org/3.0/library/array.html?highlight=array#module-array says that 'c' is a legal value. ---------- assignee: georg.brandl components: Documentation messages: 77094 nosy: georg.brandl, lopgok severity: normal status: open title: array('c') in python 3.0 produces error, doc says it is ok type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 03:10:24 2008 From: report at bugs.python.org (gumpy) Date: Sat, 06 Dec 2008 02:10:24 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228529424.11.0.233407832971.issue4509@psf.upfronthosting.co.za> gumpy added the comment: I found another related bug. In bytes_setslice, when the buffer is resized to a smaller size, a memmove happens regardless of whether the resize is successful or not. >>> b = bytearray(range(10)) >>> m = memoryview(b) >>> b[1:8] = b'X' Traceback (most recent call last): File "", line 1, in BufferError: Existing exports of data: object cannot be re-sized >>> b bytearray(b'\x00\x01\x08\t\x04\x05\x06\x07\x08\t') The same problem also applies to bytes_remove: >>> b bytearray(b'\x02\x03\x04\x05\x06\x07\x08\t') >>> b.remove(2) Traceback (most recent call last): File "", line 1, in BufferError: Existing exports of data: object cannot be re-sized >>> b bytearray(b'\x03\x04\x05\x06\x07\x08\t\x00') There may be other places this can happen but I haven't checked yet. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 03:20:16 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 02:20:16 +0000 Subject: [issue4555] Smelly exports In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> Message-ID: <1228530016.91.0.480334372163.issue4555@psf.upfronthosting.co.za> Christian Heimes added the comment: I just suggest that somebody should look into it. I neither know how critical the issue is nor how to change them. This bug report serves as a reminder. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 03:25:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 02:25:27 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> New submission from Christian Heimes : The patch adds a configure option --with-stdc89. It also fixes some edge cases in socketmodule.h and linuxaudiodev so all related modules can be build in c89 mode. I'm planning to add the configure option to the build bots in order to detect c89 incompatibilities like the usage of "inline" and // style comments. ---------- components: Build files: with_stdc89.patch keywords: patch, patch messages: 77097 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: with_stdc89 type: feature request versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12246/with_stdc89.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 03:55:30 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 06 Dec 2008 02:55:30 +0000 Subject: [issue4555] Smelly exports In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> Message-ID: <1228532130.41.0.047449255471.issue4555@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 05:11:42 2008 From: report at bugs.python.org (gumpy) Date: Sat, 06 Dec 2008 04:11:42 +0000 Subject: [issue4509] bugs in bytearray with exports (buffer protocol) In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228536702.38.0.389064785598.issue4509@psf.upfronthosting.co.za> gumpy added the comment: Sorry, forgot to give this issue a more accurate title earlier. ---------- title: possible memoryview bug -> bugs in bytearray with exports (buffer protocol) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 05:15:34 2008 From: report at bugs.python.org (Glenn Linderman) Date: Sat, 06 Dec 2008 04:15:34 +0000 Subject: [issue4485] fast swap of "default" Windows python versions In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za> Message-ID: <1228536934.59.0.336024894539.issue4485@psf.upfronthosting.co.za> Glenn Linderman added the comment: Ah yes, it could work as a front-end launcher, since # is a comment character for Python anyway, so all Pythons would ignore such a line. So that can be done completely independently of python itself, and installed separately, and used by people that choose to. In other words, feel free to write the program, and release it for all that find it useful. The sooner the better, eh? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 06:25:36 2008 From: report at bugs.python.org (gumpy) Date: Sat, 06 Dec 2008 05:25:36 +0000 Subject: [issue4509] bugs in bytearray with exports (buffer protocol) In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228541136.47.0.414208520034.issue4509@psf.upfronthosting.co.za> gumpy added the comment: I've found that arrays from the array module have similar issues: >>> a = array.array('i', range(2)) >>> m = memoryview(a) >>> bytes(m) b'\x00\x00\x00\x00\x01\x00\x00\x00' >>> a.pop(0) 0 >>> bytes(m) b'\x01\x00\x00\x00\x01\x00\x00\x00' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 07:04:14 2008 From: report at bugs.python.org (Kumar McMillan) Date: Sat, 06 Dec 2008 06:04:14 +0000 Subject: [issue4554] Missing make altframeworkinstall for Mac OS X In-Reply-To: <1228525462.29.0.299893265835.issue4554@psf.upfronthosting.co.za> Message-ID: <1228543454.35.0.52718939.issue4554@psf.upfronthosting.co.za> Changes by Kumar McMillan : ---------- nosy: +kumar303 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 09:05:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 08:05:02 +0000 Subject: [issue1569356] sys.settrace cause curried parms to show up as attributes Message-ID: <1228550702.57.0.67001938575.issue1569356@psf.upfronthosting.co.za> Georg Brandl added the comment: Assigning to the 2.4/2.5 RM. ---------- assignee: jhylton -> loewis nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 09:08:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 08:08:04 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228550884.69.0.825432124215.issue4558@psf.upfronthosting.co.za> Georg Brandl added the comment: Patch looks good. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 09:12:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 08:12:17 +0000 Subject: [issue4557] array('c') in python 3.0 produces error, doc says it is ok In-Reply-To: <1228528955.11.0.946708107115.issue4557@psf.upfronthosting.co.za> Message-ID: <1228551137.59.0.0169442591269.issue4557@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed the docs in r67605. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 09:15:06 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 08:15:06 +0000 Subject: [issue4556] cmp() function erroneously noted as gone in "What's New" In-Reply-To: <1228528682.39.0.573308363833.issue4556@psf.upfronthosting.co.za> Message-ID: <1228551306.08.0.0410602007946.issue4556@psf.upfronthosting.co.za> Georg Brandl added the comment: This can be seen as a reminder for #1717. I've "fixed" the whatsnew in r67606. ---------- assignee: georg.brandl -> gvanrossum nosy: +gvanrossum resolution: -> fixed status: open -> closed superseder: -> Get rid of more refercenes to __cmp__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 09:15:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 08:15:40 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228551340.97.0.685494154126.issue1717@psf.upfronthosting.co.za> Georg Brandl added the comment: cmp() the function is also still there. ---------- priority: high -> critical resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 10:23:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 09:23:47 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228555427.82.0.0658217020571.issue4558@psf.upfronthosting.co.za> Christian Heimes added the comment: The updated patch moves the compiler option to the right place. Added file: http://bugs.python.org/file12247/with_stdc89_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 10:45:53 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 06 Dec 2008 09:45:53 +0000 Subject: [issue1569356] sys.settrace cause curried parms to show up as attributes Message-ID: <1228556753.02.0.090632160852.issue1569356@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Because of the incompatibility in locals(), this patch cannot be backported. ---------- versions: +Python 2.6 -Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 10:55:21 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sat, 06 Dec 2008 09:55:21 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> New submission from Lennart Regebro : The whatsnew/3.0.rst document claims "It is not recommended to try to write source code that runs unchanged under both Python 2.6 and 3.0; you?d have to use a very contorted coding style, e.g. avoiding print statements, metaclasses, and much more. " This is no longer true, since 2.6 now has much backwards compatibility, including fopr print statements and unicode, so it's prefectly possible and not at all contorted to support both any longer. I'd recommend that the above statement is changed to "under both Python 2.5 and 3.0" or simply removed. ---------- assignee: georg.brandl components: Documentation messages: 77108 nosy: georg.brandl, lregebro severity: normal status: open title: Whats new recommendation error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 11:02:03 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 06 Dec 2008 10:02:03 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228557723.02.0.758776864013.issue4559@psf.upfronthosting.co.za> Raymond Hettinger added the comment: No thanks. We need to STRONGLY discourage such efforts. The official recommended approach is to run 2.6 with a -3 option to identify code that cannot be automatically converted and then after making the appropriate updates to use the 2-to-3 converter. Trying to bypass that path is asking for unnecessary pain. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 11:05:58 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sat, 06 Dec 2008 10:05:58 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228557958.08.0.792713051944.issue4559@psf.upfronthosting.co.za> Lennart Regebro added the comment: That is not true, and statement as it stands now is still factually incorrect. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 11:11:14 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 06 Dec 2008 10:11:14 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228558274.22.0.53400445306.issue4559@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, the OP wants you to change your long-standing guidance on the relationship between 2.6 and 3.0. Care to pronounce? ---------- assignee: georg.brandl -> gvanrossum nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 12:23:48 2008 From: report at bugs.python.org (Jonathan Feinberg) Date: Sat, 06 Dec 2008 11:23:48 +0000 Subject: [issue4560] "Flouted", not "flaunted" In-Reply-To: <1228562627.9.0.790263792312.issue4560@psf.upfronthosting.co.za> Message-ID: <1228562627.9.0.790263792312.issue4560@psf.upfronthosting.co.za> New submission from Jonathan Feinberg : http://docs.python.org/3.0/whatsnew/3.0.html#library-changes "Some modules were renamed because their old name flaunted PEP 0008" should read "Some modules were renamed because their old name flouted PEP 0008". ---------- assignee: georg.brandl components: Documentation messages: 77112 nosy: georg.brandl, jdf severity: normal status: open title: "Flouted", not "flaunted" versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 12:32:03 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 11:32:03 +0000 Subject: [issue4560] "Flouted", not "flaunted" In-Reply-To: <1228562627.9.0.790263792312.issue4560@psf.upfronthosting.co.za> Message-ID: <1228563123.92.0.958963218573.issue4560@psf.upfronthosting.co.za> Georg Brandl added the comment: It's already "disobeyed" in SVN. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 12:45:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 06 Dec 2008 11:45:37 +0000 Subject: [issue1163367] correct/clarify documentation for super Message-ID: <1228563937.87.0.988870178405.issue1163367@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Updated again in r67607. Hopefully, this one has been put to rest. If someone has further issues with the super() docs, please open a new report (preferably with suggested wording). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 12:57:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 11:57:52 +0000 Subject: [issue4488] Python Documentation not Newb Friendly In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za> Message-ID: <1228564672.29.0.233618210157.issue4488@psf.upfronthosting.co.za> Georg Brandl added the comment: You are quite right. I've given PIPE and STDOUT their own entries now in r67608. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 13:14:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 12:14:51 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> New submission from Christian Heimes : The new io library needs some serious profiling and optimization work. I've already fixed a severe slowdown in _fileio.FileIO's read buffer allocation algorithm (#4533). More profiling tests have shown a speed problem in write() files opened in text mode. For example three str.count() calls are taking up 20% of the time. The str.count calls can be replaced with an optimized C function that returns the count of (\r\n, \n, \r) in one pass instead of three passes. ---------- components: Extension Modules, Library (Lib) messages: 77116 nosy: christian.heimes priority: high severity: normal stage: test needed status: open title: Optimize new io library type: performance versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 13:30:27 2008 From: report at bugs.python.org (David M. Beazley) Date: Sat, 06 Dec 2008 12:30:27 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228566627.47.0.52410737613.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: I've done some profiling and the performance of reading line-by-line is considerably worse in Python 3 than in Python 2. For example, this code: for line in open("somefile.txt"): pass Ran 35 times slower in Python 3.0 than Python 2.6 when I tested it on a big text file (100 Megabytes). If you disable Unicode by opening the file in binary mode, it runs even slower. This slowdown is really unacceptable for anyone who uses Python for parsing big non-Unicode text files (and I would claim that there are many such people). ---------- nosy: +beazley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 13:32:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 12:32:29 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228566749.86.0.722952561106.issue4561@psf.upfronthosting.co.za> Christian Heimes added the comment: Your issue is most like caused by #4533. Please download the latest svn version of Python 3.0 (branches/release30_maint) and try again. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 13:46:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Dec 2008 12:46:04 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228529424.11.0.233407832971.issue4509@psf.upfronthosting.co.za> Message-ID: <1228567561.12039.5.camel@localhost> Antoine Pitrou added the comment: > There may be other places this can happen but I haven't checked yet. PyByteArray_Resize() is called in various places in bytearrayobject.c, some of them where it is mandatory to mutate the underlying storage before reallocating it. The solution would be to have a separate function to check whether resizing is allowed (but it would not solve the problem in the face of MemoryErrors). ---------- title: bugs in bytearray with exports (buffer protocol) -> possible memoryview bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 14:22:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 13:22:09 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228569729.3.0.421281635525.issue4561@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is a patch againt the py3k branch that reduces the time for the line ending detection from 0.55s to 0.22s for a 50MB file on my test system. ---------- keywords: +patch Added file: http://bugs.python.org/file12248/count_linenendings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 14:24:45 2008 From: report at bugs.python.org (Santiago Gala) Date: Sat, 06 Dec 2008 13:24:45 +0000 Subject: [issue3206] Multiprocessing Array and sharedctypes.Array error in docs/implementation In-Reply-To: <1214473998.34.0.913565828871.issue3206@psf.upfronthosting.co.za> Message-ID: <1228569885.63.0.360831088761.issue3206@psf.upfronthosting.co.za> Santiago Gala added the comment: Note that if the error is in the documentation semantics, and not in the implementation, then the benchmark code in the documentation is also broken, and should be change to not use lock=True/False respectively... I'm not sure if the patch here is good or rather lock=True/False should be the right API and the implementation should be changed along this lines: diff --git a/Lib/multiprocessing/sharedctypes.py b/Lib/multiprocessing/sharedctypes.py index b94cd52..2f68e74 100644 --- a/Lib/multiprocessing/sharedctypes.py +++ b/Lib/multiprocessing/sharedctypes.py @@ -79,10 +79,11 @@ def Array(typecode_or_type, size_or_initializer, **kwds): if kwds: raise ValueError('unrecognized keyword argument(s): %s' % list(kwds.keys())) obj = RawArray(typecode_or_type, size_or_initializer) - if lock is None: + if lock is True: lock = RLock() - assert hasattr(lock, 'acquire') - return synchronized(obj, lock) + return synchronized(obj, lock) + return obj + def copy(obj): new_obj = _new_value(type(obj)) ---------- nosy: +sgala _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 14:25:10 2008 From: report at bugs.python.org (Floris Bruynooghe) Date: Sat, 06 Dec 2008 13:25:10 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228569910.36.0.237126371075.issue4483@psf.upfronthosting.co.za> Floris Bruynooghe added the comment: Hi, I'd like to confirm that Skip's last patch fixes the issue. Hope it gets included soon! Thanks ---------- nosy: +flub _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 14:31:46 2008 From: report at bugs.python.org (Santiago Gala) Date: Sat, 06 Dec 2008 13:31:46 +0000 Subject: [issue3206] Multiprocessing Array and sharedctypes.Array error in docs/implementation In-Reply-To: <1214473998.34.0.913565828871.issue3206@psf.upfronthosting.co.za> Message-ID: <1228570306.85.0.417599954173.issue3206@psf.upfronthosting.co.za> Santiago Gala added the comment: oops, there is a proper code patch in issue4449 , and the documentation is right. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 14:42:18 2008 From: report at bugs.python.org (David M. Beazley) Date: Sat, 06 Dec 2008 13:42:18 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228570938.99.0.241195080017.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: Tried this using projects/python/branches/release30-maint and using the patch that was just attached. With a 66MB input file, here are the results of this code fragment: for line in open("BIGFILE): pass Python 2.6: 0.67s Python 3.0: 32.687s (48 times slower) This is running on a MacBook with a warm disk cache. For what it's worth, I didn't see any improvement with that patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 14:45:47 2008 From: report at bugs.python.org (David M. Beazley) Date: Sat, 06 Dec 2008 13:45:47 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228571147.23.0.466268871188.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: Just as one other followup, if you change the code in the last example to use binary mode like this: for line in open("BIG","rb"): pass You get the following results: Python 2.6: 0.64s Python 3.0: 42.26s (66 times slower) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 15:16:28 2008 From: report at bugs.python.org (Mariano M. Chouza) Date: Sat, 06 Dec 2008 14:16:28 +0000 Subject: [issue4562] zip() documentation was not updated In-Reply-To: <1228572988.54.0.0100551615792.issue4562@psf.upfronthosting.co.za> Message-ID: <1228572988.54.0.0100551615792.issue4562@psf.upfronthosting.co.za> New submission from Mariano M. Chouza : zip() function documentatio still shows the old behavior of the function, returning a list. http://docs.python.org/3.0/library/functions.html?highlight=zip#zip ---------- assignee: georg.brandl components: Documentation messages: 77126 nosy: georg.brandl, mchouza severity: normal status: open title: zip() documentation was not updated versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 15:29:05 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 14:29:05 +0000 Subject: [issue4562] zip() documentation was not updated In-Reply-To: <1228572988.54.0.0100551615792.issue4562@psf.upfronthosting.co.za> Message-ID: <1228573745.65.0.697380899156.issue4562@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67609. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 15:29:27 2008 From: report at bugs.python.org (Ori Avtalion) Date: Sat, 06 Dec 2008 14:29:27 +0000 Subject: [issue4563] Wrong formatting of contributor list in About page In-Reply-To: <1228573767.66.0.95540674758.issue4563@psf.upfronthosting.co.za> Message-ID: <1228573767.66.0.95540674758.issue4563@psf.upfronthosting.co.za> New submission from Ori Avtalion : The bulleted list of credits in the about page is turning people's initials into numbering. For example: * A. Amoroso * L. Peter Deutsch appear as * 1. Amoroso * 12. Peter Deutsch ---------- assignee: georg.brandl components: Documentation messages: 77128 nosy: georg.brandl, salty-horse severity: normal status: open title: Wrong formatting of contributor list in About page versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 15:33:03 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 14:33:03 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228573983.35.0.168363198709.issue4561@psf.upfronthosting.co.za> Georg Brandl added the comment: David, the reading bug fix/optimization is not (yet?) on release30-maint, only on branches/py3k. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 15:56:43 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Dec 2008 14:56:43 +0000 Subject: [issue4564] bytearray.fromhex doesn't respect bytearray subclass In-Reply-To: <1228575403.73.0.337018750151.issue4564@psf.upfronthosting.co.za> Message-ID: <1228575403.73.0.337018750151.issue4564@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The following code says it all: >>> class B(bytearray): pass ... >>> b = B.fromhex("0c0a") >>> b bytearray(b'\x0c\n') >>> isinstance(b, B) False ---------- messages: 77130 nosy: pitrou priority: normal severity: normal status: open title: bytearray.fromhex doesn't respect bytearray subclass type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 15:57:26 2008 From: report at bugs.python.org (David M. Beazley) Date: Sat, 06 Dec 2008 14:57:26 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228575446.32.0.193209165606.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: Just checked it with branches/py3k and the performance is the same. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:08:14 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 06 Dec 2008 15:08:14 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1228576094.12.0.245156579739.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:11:00 2008 From: report at bugs.python.org (Istvan Albert) Date: Sat, 06 Dec 2008 15:11:00 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> New submission from Istvan Albert : The write performance into text files is substantially slower (5x-8x) than that of python 2.5. This makes python 3.0 unsuited to any application that needs to write larger amounts of data. ------------test code follows ----------------------- import time lo, hi, step = 10**5, 10**6, 10**5 # writes increasingly more lines to a file for N in range(lo, hi, step): fp = open('foodata.txt', 'wt') start = time.time() for i in range( N ): fp.write( '%s\n' % i) fp.close() stop = time.time() print ( "%s\t%s" % (N, stop-start) ) ---------- components: Interpreter Core messages: 77132 nosy: ialbert severity: normal status: open title: io write() performance very slow type: performance versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:28:55 2008 From: report at bugs.python.org (Craig Holmquist) Date: Sat, 06 Dec 2008 15:28:55 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> New submission from Craig Holmquist : Applications on Windows that don't link to the MSVCR90.DLL via a manifest are broken with Python 2.6.1. This includes apps that link with the C library statically and apps that link with other versions of it. These applications worked fine with Python 2.6. To test this, I created a simple application that did nothing but call Py_Main (compiled with VS2008). When that app links with the C library statically, attempting to import the socket module gives this error: Traceback (most recent call last): File "", line 1, in File "C:\Python26\lib\socket.py", line 46, in import _socket ImportError: DLL load failed: The specified module could not be found. When that app links with the C library dynamically, it works properly. In particular, this issue breaks mod_python. From the Apache error log: [Sat Dec 06 00:49:21 2008] [error] make_obcallback: could not import mod_python.apache.\n Traceback (most recent call last): File "C:\Python26\lib\site-packages\mod_python\apache.py", line 29, in import cgi File "C:\Python26\Lib\cgi.py", line 40, in import urllib File "C:\Python26\Lib\urllib.py", line 26, in import socket File "C:\Python26\lib\socket.py", line 46, in import _socket ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. I'm guessing this is a side-effect of the fix for #4120. Since modules like _socket.pyd don't have manifests that tell Windows where to find the side-by-side assembly to load, and the application loading _socket.pyd doesn't have it in its manifest either, Windows has no clue where to find MSVCR90.dll. Something I discovered (by accident) is that, if there's an external manifest in the same folder as the hosting application (ie, testpy.exe.manifest) that points to the C runtime, it fixes the problem, even if the host app links statically to the C runtime. I don't recall off-hand whether these external manifests take precedence over the internal ones, but in this case it seems to provide enough information to Windows that it can resolve the dependency. ---------- components: Windows messages: 77133 nosy: craigh severity: normal status: open title: 2.6.1 breaks many applications that embed Python on Windows type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:30:34 2008 From: report at bugs.python.org (Craig Holmquist) Date: Sat, 06 Dec 2008 15:30:34 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228577434.01.0.60450082206.issue4566@psf.upfronthosting.co.za> Changes by Craig Holmquist : Added file: http://bugs.python.org/file12249/testpy.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:30:49 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 06 Dec 2008 15:30:49 +0000 Subject: [issue4199] add shorthand global and nonlocal statements In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za> Message-ID: <1228577449.54.0.284726917474.issue4199@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: - the add_ast_fields() function seems to be added by this patch, but it is already in svn. - Are 1-tuple supported? t = [1] global a, = t ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:31:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Dec 2008 15:31:36 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228577496.33.0.456008051957.issue4509@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New bytearray patch at http://codereview.appspot.com/10049. I think I've covered all bases. array.array will need another patch (I must admit I care a bit less about it, since it's not a builtin type). The patch will have to be backported for 2.6/2.7 as well, but memoryview doesn't exist there, so the tests will have to be disabled. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:32:05 2008 From: report at bugs.python.org (Craig Holmquist) Date: Sat, 06 Dec 2008 15:32:05 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228577525.09.0.310927397471.issue4566@psf.upfronthosting.co.za> Craig Holmquist added the comment: I've attached the test program I was using. The commands I used to compile it are: cl /MT /c /IC:\Python26\include testpy.c link /LIBPATH:C:\Python26\libs testpy.obj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:34:04 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 06 Dec 2008 15:34:04 +0000 Subject: [issue4445] String allocations waste 3 bytes of memory on average. In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za> Message-ID: <1228577644.84.0.554245600677.issue4445@psf.upfronthosting.co.za> Mark Dickinson added the comment: Applied to py3k in r67610. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:40:25 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 06 Dec 2008 15:40:25 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228578025.82.0.291873175994.issue4565@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This is expected: the I/O stack has been completely rewritten... in almost pure-python code. There is a project to rewrite it in C. It started at http://svn.python.org/view/sandbox/trunk/io-c/ ---------- assignee: -> amaury.forgeotdarc nosy: +amaury.forgeotdarc priority: -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:53:58 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 06 Dec 2008 15:53:58 +0000 Subject: [issue4564] bytearray.fromhex doesn't respect bytearray subclass In-Reply-To: <1228575403.73.0.337018750151.issue4564@psf.upfronthosting.co.za> Message-ID: <1228578838.12.0.908267102715.issue4564@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The same kind of request has been rejected several times: issue2267, issue1562. The explanation given is here: http://mail.python.org/pipermail/python-list/2005-January/300791.html """a base class has no idea what requirements may exist for invoking a subclass's constructor""" ---------- nosy: +amaury.forgeotdarc resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:58:02 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 06 Dec 2008 15:58:02 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228579082.6.0.0191147855167.issue4506@psf.upfronthosting.co.za> Mark Dickinson added the comment: The segfault is a little worrying; I don't understand that at all. Skip, can you come up with a configure patch that would allow isinf to be detected on Solaris? I'll also patch Py_IS_INFINITY to make sure that it forces its argument into memory before testing it; this *should* fix the problem on platforms that don't have isinf. (Note to self: first find out whether Py_IS_INFINITY is ever applied to single precision floats, or whether we can assume the argument is always a double.) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:17:07 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 06 Dec 2008 16:17:07 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228580227.66.0.864370657489.issue4558@psf.upfronthosting.co.za> Roumen Petrov added the comment: There is no reason to overload configure script. Please look into pyport.h : #define Py_LOCAL(type) static type #define Py_LOCAL_INLINE(type) static inline type Someone add USE_INLINE - not finished. I guess that other source files has to use macros from one header(pyport.h) instead every C-file to resolve issue independently. ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:23:13 2008 From: report at bugs.python.org (Craig Holmquist) Date: Sat, 06 Dec 2008 16:23:13 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228580593.93.0.635871589943.issue4566@psf.upfronthosting.co.za> Craig Holmquist added the comment: I've attached a manifest file that references the C runtime; adding this file to the Apache bin folder seems to workaround this issue. Added file: http://bugs.python.org/file12250/httpd.exe.manifest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:42:18 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2008 16:42:18 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228581738.28.0.904273730433.issue1717@psf.upfronthosting.co.za> Guido van Rossum added the comment: Bah. That means we'll have to start deprecating cmp() in 3.1, and won't be able to remove it until 3.2 or 3.3. :-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:47:22 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 16:47:22 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228582042.59.0.407998864333.issue4558@psf.upfronthosting.co.za> Christian Heimes added the comment: I think you don't get the point of the patch. The configure option *enforces* the C89 standard. Every non C89 conform C feature like // comments and the "inline" keyword will cause a compiler error. The patch is meant for testing the Python code on the build bots. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:51:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 16:51:30 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228582290.37.0.225579146959.issue4561@psf.upfronthosting.co.za> Christian Heimes added the comment: What's your OS, David? Please post the output of "uname -r" and ./python -c "import sys; print(sys.version)" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:52:11 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 06 Dec 2008 16:52:11 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228582331.05.0.212850311192.issue4558@psf.upfronthosting.co.za> Roumen Petrov added the comment: Christian did you like to propose a separate configure flag for every dialect that GCC support? I prefer variables like OPT. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:52:49 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 06 Dec 2008 16:52:49 +0000 Subject: [issue3167] math test fails on Solaris 10 In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za> Message-ID: <1228582369.43.0.573446643216.issue3167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Skip, Jean: Could you try the attached patch to see if it fixes the math.log and math.log10 test failures. (The patch is generated against the trunk, but should apply cleanly to py3k or either of the 2.6 or 3.0 maintenance branches. Added file: http://bugs.python.org/file12251/math_log.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:53:34 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 06 Dec 2008 16:53:34 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228582414.0.0.644351049331.issue4558@psf.upfronthosting.co.za> Roumen Petrov added the comment: P.S. About C++ comments ( // ) I think that another issue is already opened (problem on AIX ? ) . _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:55:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 16:55:51 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228582551.86.0.912952622573.issue4558@psf.upfronthosting.co.za> Christian Heimes added the comment: Python core code must be compliant with the C89 standard but we don't have any checks for C89 compatibility. This patch adds a clean way to check our code base. You can verify my patch by adding a // comment somewhere in the code and ./configure --with-stdc89 && make. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:57:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 06 Dec 2008 16:57:26 +0000 Subject: [issue3682] test_math: math.log(-ninf) fails to raise exception on OpenBSD In-Reply-To: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za> Message-ID: <1228582646.05.0.88179053606.issue3682@psf.upfronthosting.co.za> Mark Dickinson added the comment: Damien, if you're still there: Please could you try the patch "math_log.patch" attached to issue 3167, and let me know whether it fixes the test failure? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 18:17:25 2008 From: report at bugs.python.org (n03702) Date: Sat, 06 Dec 2008 17:17:25 +0000 Subject: [issue1597850] Cross compiling patches for MINGW Message-ID: <1228583845.31.0.0554634751816.issue1597850@psf.upfronthosting.co.za> n03702 added the comment: There is port of cross-2.6-0.7.diff patch for python 3.0 final ---------- nosy: +n03702 Added file: http://bugs.python.org/file12252/cross-3.0-0.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 18:21:07 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 06 Dec 2008 17:21:07 +0000 Subject: [issue3167] math test fails on Solaris 10 In-Reply-To: <1228582369.43.0.573446643216.issue3167@psf.upfronthosting.co.za> Message-ID: <18746.46206.433323.53161@montanaro-dyndns-org.local> Skip Montanaro added the comment: Mark> Could you try the attached patch to see if it fixes the math.log Mark> and math.log10 test failures. (The patch is generated against the Mark> trunk, but should apply cleanly to py3k or either of the 2.6 or Mark> 3.0 maintenance branches. Seems to work on Sol10 for me: % ./python Lib/test/regrtest.py -v test_math test_math testAcos (test.test_math.MathTests) ... ok testAcosh (test.test_math.MathTests) ... ok testAsin (test.test_math.MathTests) ... ok testAsinh (test.test_math.MathTests) ... ok testAtan (test.test_math.MathTests) ... ok testAtan2 (test.test_math.MathTests) ... ok testAtanh (test.test_math.MathTests) ... ok testCeil (test.test_math.MathTests) ... ok testConstants (test.test_math.MathTests) ... ok testCopysign (test.test_math.MathTests) ... ok testCos (test.test_math.MathTests) ... ok testCosh (test.test_math.MathTests) ... ok testDegrees (test.test_math.MathTests) ... ok testExp (test.test_math.MathTests) ... ok testFabs (test.test_math.MathTests) ... ok testFactorial (test.test_math.MathTests) ... ok testFloor (test.test_math.MathTests) ... ok testFmod (test.test_math.MathTests) ... ok testFrexp (test.test_math.MathTests) ... ok testFsum (test.test_math.MathTests) ... ok testHypot (test.test_math.MathTests) ... ok testIsinf (test.test_math.MathTests) ... ok testIsnan (test.test_math.MathTests) ... ok testLdexp (test.test_math.MathTests) ... ok testLog (test.test_math.MathTests) ... ok testLog10 (test.test_math.MathTests) ... ok testLog1p (test.test_math.MathTests) ... ok testModf (test.test_math.MathTests) ... ok testPow (test.test_math.MathTests) ... ok testRadians (test.test_math.MathTests) ... ok testSin (test.test_math.MathTests) ... ok testSinh (test.test_math.MathTests) ... ok testSqrt (test.test_math.MathTests) ... ok testTan (test.test_math.MathTests) ... ok testTanh (test.test_math.MathTests) ... ok test_exceptions (test.test_math.MathTests) ... ok test_testfile (test.test_math.MathTests) ... ok test_trunc (test.test_math.MathTests) ... ok Doctest: ieee754.txt ... ok ---------------------------------------------------------------------- Ran 39 tests in 0.237s OK 1 test OK. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 18:35:12 2008 From: report at bugs.python.org (Benoit Boissinot) Date: Sat, 06 Dec 2008 17:35:12 +0000 Subject: [issue2848] Remove mimetools usage from the stdlib In-Reply-To: <1210726775.09.0.0627957766628.issue2848@psf.upfronthosting.co.za> Message-ID: <1228584912.03.0.449103013789.issue2848@psf.upfronthosting.co.za> Benoit Boissinot added the comment: > Why does it need to be in 2.6? mimetools is still there. Because it outputs a warning with python2.6 -3, it's annoying for people trying to port their application to python3k ---------- nosy: +bboissin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 18:53:34 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 06 Dec 2008 17:53:34 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228586014.94.0.642312986753.issue4483@psf.upfronthosting.co.za> Skip Montanaro added the comment: Fix checked in for py3k (r67612), release26-maint (r67613), release30-maint (r67615) branches as well as trunk (r67614). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:14:06 2008 From: report at bugs.python.org (Stuart Axon) Date: Sat, 06 Dec 2008 18:14:06 +0000 Subject: [issue4567] Registry key not set if unattended installation used In-Reply-To: <1228587246.7.0.370739440379.issue4567@psf.upfronthosting.co.za> Message-ID: <1228587246.7.0.370739440379.issue4567@psf.upfronthosting.co.za> New submission from Stuart Axon : If the msi is installed with /quiet it installs to the default location, but the registry key is not set, making it harder for other programs to find the installation. - in my case I had to make a batch file that installed it, then read the log file to find this information, which is less than ideal. ---------- components: Installation messages: 77155 nosy: stuaxo severity: normal status: open title: Registry key not set if unattended installation used type: behavior versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:19:21 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 06 Dec 2008 18:19:21 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228587561.66.0.256083191263.issue4558@psf.upfronthosting.co.za> Roumen Petrov added the comment: make EXTRA_CFLAGS='-std=c89' works for me. Added file: http://bugs.python.org/file12253/python-trunk-20081206-c89.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:25:14 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2008 18:25:14 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228587914.33.0.010020147395.issue4559@psf.upfronthosting.co.za> Guido van Rossum added the comment: It is true for 2.6 unless you use various from __future__ imports, which I consider a form of contortion. Even with 2.6 I don't see how you can specify a metaclass without doing something weird like foo = MyMetaclass('foo', bases_tuple, namespace_dict) which is hardly an improvement over either the 2.x or 3.0 syntax. Given that it will always be true for 2.5, I don't want to back down. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:26:59 2008 From: report at bugs.python.org (Istvan Albert) Date: Sat, 06 Dec 2008 18:26:59 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228588019.17.0.814896776122.issue4565@psf.upfronthosting.co.za> Istvan Albert added the comment: Well I would strongly dispute that anyone other than the developers expected this. The release documentation states: "The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5." There is no indication of an order of magnitudes in read/write slowdown. I believe that this issue is extremely serious! IO is an essential part of a program, and today we live in the world of gigabytes of data. I am reading reports of even more severe io slowdowns than what I saw: http://bugs.python.org/issue4561 Java has had a hard time getting rid of the "it is very slow" stigma even after getting a JIT compiler, so there is a danger there for a lasting negative impression. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:28:38 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 06 Dec 2008 18:28:38 +0000 Subject: [issue4199] add shorthand global and nonlocal statements In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za> Message-ID: <1228588118.18.0.731519728687.issue4199@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think I may have been merging add_ast_fields when I wrote the patch. Here's a new patch that handles "global x, = (5,)". To do it, I added a new flag* to the Global and Nonlocal AST objects that indicates whether the value needs to be unpacked or not. * The flag is an int. The bool AST type was removed in py3k. Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:31:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 06 Dec 2008 18:31:08 +0000 Subject: [issue4084] Decimal.max(NaN, x) gives incorrect results when x is finite and long In-Reply-To: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za> Message-ID: <1228588268.14.0.0968560561154.issue4084@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:45:34 2008 From: report at bugs.python.org (David M. Beazley) Date: Sat, 06 Dec 2008 18:45:34 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228589134.58.0.519375442005.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: bash-3.2$ uname -a Darwin david-beazleys-macbook.local 9.5.1 Darwin Kernel Version 9.5.1: Fri Sep 19 16:19:24 PDT 2008; root:xnu-1228.8.30~1/RELEASE_I386 i386 bash-3.2$ ./python.exe -c "import sys; print(sys.version)" 3.1a0 (py3k:67609, Dec 6 2008, 08:47:06) [GCC 4.0.1 (Apple Inc. build 5465)] bash-3.2$ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:59:34 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sat, 06 Dec 2008 18:59:34 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228589974.93.0.249866716031.issue4559@psf.upfronthosting.co.za> Lennart Regebro added the comment: A future import is not much of a contortion, and metaclasses is not exactly an everyday occurrence, after 9 years of python I have yet to write a metaclass... Of course I don't like that it specifically mentiones 2.6, while 2.6 has lot's of forwards compatibility just to make it possible to write code that runs under both. It will always be true for 2.5, and then we could fix the issue by changing 2.6 to 2.5. If you want to keep the statement for 2.6, it could possibly be reformulated less strongly, or as a minimum change come up with another example than something that actually has a forward compatibility in 2.6. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 20:03:45 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 06 Dec 2008 19:03:45 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228590225.01.0.948897246133.issue4506@psf.upfronthosting.co.za> Skip Montanaro added the comment: > can you come up with a configure patch that would allow isinf to be > detected on Solaris? The plot thickens. I know squat about autoconf sorts of things so I asked on the autoconf mailing list. Eric Drake responded (in part): The Python ACHECK_FUNCS test should be rewritten (with proper m4 quoting) as: AC_CHECK_FUNCS([acosh asinh atanh expm1 finite log1p]) AC_CHECK_DECLS([isinf, isnan], [], [], [[#include ]]) so I gave that a whirl. Whaddya know? isinf *really* isn't available, at least not until C99 apparently. The AC_CHECK_DECLS macro generates a conftest.c which looks like this: #include int main () { #ifndef isinf (void) isinf; #endif ; return 0; } which fails to compile/link on our Sol10 boxes. Turns out libm.so doesn't export an _isinf symbol. The macro I found (in iso/math_c99.h) doesn't expand in gcc -E output of the above code, so in my non-c99 environment I don't get to use isinf. Looks like your Py_IS_INFINITY fix will be necessary. Eric also suggested using the gnu isinf and isnan modules: http://git.savannah.gnu.org/gitweb/? p=gnulib.git;a=blob;f=m4/isinf.m4;h=1b9e45a;hb=67461c3 I'll leave that for you to decide. In any case, the above changes to AC_CHECK_FUNCS should probably be made. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 20:07:24 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2008 19:07:24 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228590444.65.0.515059694162.issue4559@psf.upfronthosting.co.za> Guido van Rossum added the comment: You're misrepresenting or misunderstanding the goal of 2.6. Its goal isn't to make it easy to write code that runs under both. Its stated goal is to make it easy to write code that can easily be *ported* to 3.0. That's a very different story. I will not be taking it back. If you want further discussion on this, open a thread on python-dev. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 20:10:01 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sat, 06 Dec 2008 19:10:01 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228590601.23.0.830845129345.issue4559@psf.upfronthosting.co.za> Lennart Regebro added the comment: I've never said that is the goal. You are misrepresenting or misinterpreting my standpoint. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 20:14:40 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2008 19:14:40 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228590880.99.0.140362718065.issue4559@psf.upfronthosting.co.za> Guido van Rossum added the comment: Then what did you mean by "just to make it possible to write code that runs under both" ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 20:18:51 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sat, 06 Dec 2008 19:18:51 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228591131.7.0.512738157156.issue4559@psf.upfronthosting.co.za> Lennart Regebro added the comment: Well, that *is* the intention of a from __future__ import, isn't it? That doesn't mean that's the intention of 2.6 as a whole, just that statement. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 21:15:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2008 20:15:07 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228594507.12.0.751052962727.issue4559@psf.upfronthosting.co.za> Guido van Rossum added the comment: But that's all part of the "make it easy to port" strategy. I stick to my claim that trying to write code that runs unchanged in 3.0 is a non-goal of Python 2.6, and I do not want to suggest that this is a good idea in the official documentation. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 21:59:10 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 06 Dec 2008 20:59:10 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228597150.12.0.589355336529.issue4483@psf.upfronthosting.co.za> Roumen Petrov added the comment: now 2008-12-06 trunk fail on linux ---------- nosy: +rpetrov versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 22:07:01 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 06 Dec 2008 21:07:01 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228597621.54.0.49939567903.issue4483@psf.upfronthosting.co.za> Roumen Petrov added the comment: may be patch is not applied correctly : http://svn.python.org/view/python/trunk/setup.py?rev=67614&view=auto libraries = gdbm_libs ) ) ? exts.append( Extension('dbm', ['dbmmodule.c'], ? define_macros=[('HAVE_GDBM_NDBM_H',None)], ? libraries = ['gdbm'] ) ) elif db_incs is not None: _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 22:36:25 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 06 Dec 2008 21:36:25 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228599385.38.0.303371395206.issue4565@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 22:36:39 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 06 Dec 2008 21:36:39 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228599399.77.0.833250612582.issue4561@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 22:37:35 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 06 Dec 2008 21:37:35 +0000 Subject: [issue4528] test_httpservers consistently fails on OS X In-Reply-To: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za> Message-ID: <1228599455.22.0.346819402568.issue4528@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 22:40:50 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Dec 2008 21:40:50 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228599650.34.0.854234949779.issue4561@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 22:52:38 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Dec 2008 21:52:38 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228600358.67.0.462633193618.issue4565@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi Amaury, > There is a project to rewrite it in C Thanks for publicizing this. I'm a bit surprised by the adopted approach. It seems you are merely translating the Python code into C. I think the proper approach for the buffered IO classes would be to use a fixed-size buffer which never gets reallocated. If you look at bufferedwriter2.patch in #3476, I had rewritten BufferedWriter using a fixed-size buffer (although not for performance reasons), I think it would be a good starting point for a C implementation. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:01:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 22:01:04 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228600864.66.0.80997130755.issue4565@psf.upfronthosting.co.za> Christian Heimes added the comment: For more bug reports see #4533 and #4561. I suggest we close this bug report as duplicate and keep the discussion in #4561. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:05:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 22:05:19 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228601119.37.0.752470441562.issue4561@psf.upfronthosting.co.za> Christian Heimes added the comment: I've updated the patch with proper formatting, some minor cleanups and a unit test. Added file: http://bugs.python.org/file12255/count_linenendings2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:05:25 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 22:05:25 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228601125.51.0.603216174942.issue4561@psf.upfronthosting.co.za> Changes by Christian Heimes : Removed file: http://bugs.python.org/file12248/count_linenendings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:09:11 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 22:09:11 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228601351.42.0.61261838026.issue1717@psf.upfronthosting.co.za> Georg Brandl added the comment: I hope the smiley really indicates a joke... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:12:54 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2008 22:12:54 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228601574.12.0.84842788223.issue1717@psf.upfronthosting.co.za> Guido van Rossum added the comment: Well what would you suggest we do? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:15:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Dec 2008 22:15:52 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228601752.28.0.436203032785.issue1717@psf.upfronthosting.co.za> Georg Brandl added the comment: I'd release 3.0.1 quickly, maybe also with the in-development improvements to the io library that alleviate the factor-1000 slowdowns. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:19:34 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Dec 2008 22:19:34 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228601974.41.0.982514432935.issue4561@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think this is a public API, so the function should probably be renamed _count_lineendings. Also, are there some benchmark numbers? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:30:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 22:30:29 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228602629.11.0.119030944911.issue4561@psf.upfronthosting.co.za> Christian Heimes added the comment: I'll come up with some reading benchmarks tomorrow. For now here is a benchmark of write(). You can clearly see the excessive usage of closed, len() and isinstance(). Added file: http://bugs.python.org/file12256/test_write.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:30:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 22:30:48 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228602648.56.0.64438867229.issue4561@psf.upfronthosting.co.za> Changes by Christian Heimes : Removed file: http://bugs.python.org/file12256/test_write.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:31:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 22:31:19 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228602679.93.0.805635241386.issue4561@psf.upfronthosting.co.za> Christian Heimes added the comment: Roundup doesn't display .log files as plain text files. Added file: http://bugs.python.org/file12257/test_write.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:39:01 2008 From: report at bugs.python.org (Brett Cannon) Date: Sat, 06 Dec 2008 22:39:01 +0000 Subject: [issue2848] Remove mimetools usage from the stdlib In-Reply-To: <1210726775.09.0.0627957766628.issue2848@psf.upfronthosting.co.za> Message-ID: <1228603141.19.0.183878090292.issue2848@psf.upfronthosting.co.za> Brett Cannon added the comment: Benoit has a good point, so I have opened this issue again so we can get 2.7 even closer to 3.x compatibility. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:48:38 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 06 Dec 2008 22:48:38 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228603718.23.0.209098567864.issue4565@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > I'm a bit surprised by the adopted approach. > It seems you are merely translating the Python code into C. > I think the proper approach for the buffered IO classes would be > to use a fixed-size buffer which never gets reallocated. You are certainly right, but the code io.py is already difficult to understand and maintain; the corresponding C code adds one level of complexity; had I changed the buffering strategy at the same time, it would have been impossible to ensure a correct implementation. Now that my C implementation of the Buffered classes seems correct (all tests pass, except a few about destructors) we could try alternative approaches. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:49:53 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 06 Dec 2008 22:49:53 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228603793.72.0.744488159109.issue1717@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:57:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 06 Dec 2008 22:57:49 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228604269.58.0.666349737534.issue4566@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I would claim that this is not a bug. There is simpler no other way to deal with this entire SxS mess. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:58:15 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 06 Dec 2008 22:58:15 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228604295.86.0.579910517172.issue1717@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Since cmp() was documented as removed in whatsnew3.0, it may be fair game to complete the removal, treating it as a bugfix. If as Georg suggests it is done *very* quickly in 3.0.1 (say in the next week or so), it is likely harmless and better than living with a half-removed feature for the next three years. Also, Georg intimated, we will likely need to do 3.0.1 almost immediately anyway (the current state of affairs with IO borders on the unusable. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:58:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 22:58:59 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228604339.57.0.309401049253.issue4566@psf.upfronthosting.co.za> Christian Heimes added the comment: A mess it is :/ ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:04:07 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 06 Dec 2008 23:04:07 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228604647.53.0.187342512341.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: A quick ballot on #python-dev resulted in 3 of 3 votes for removing cmp() in a quick bug fix release. About the io misery: My quick fix for the buffer reallocation schema has made the situation a bit better. For the 3.0.x series I like to discuss if we shouldo declare critical performance fixes as bug fixes and not as new features. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:09:38 2008 From: report at bugs.python.org (Gregg Lind) Date: Sat, 06 Dec 2008 23:09:38 +0000 Subject: [issue4568] Improved optparse "varargs" callback example In-Reply-To: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za> Message-ID: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za> New submission from Gregg Lind : In the trunk (r67617) documentation for *optparse* callback example 6 doesn't handle negative number arguments, and fixing it is "left as an exercise for the reader." Well, I'm a reader, and I've attached my stab at it. Caveat: It relies in trying to coerce the argument into a float... maybe there's a cleaner way to do it? (This is my first patch, so I apologize if I've fouled it up in some way, particularly in the headers of the patch format.) ---------- assignee: georg.brandl components: Documentation files: better_optparse_varargs_example.diff keywords: patch messages: 77185 nosy: georg.brandl, gregg.lind severity: normal status: open title: Improved optparse "varargs" callback example Added file: http://bugs.python.org/file12258/better_optparse_varargs_example.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:21:32 2008 From: report at bugs.python.org (gumpy) Date: Sat, 06 Dec 2008 23:21:32 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228605692.57.0.745414993844.issue4509@psf.upfronthosting.co.za> gumpy added the comment: It turns out the problems in array are more serious than I thought and allow writing to unallocated memory through a memoryview leading to memory corruption, segfaults and possibly exploits. The following example extends an array enough to trigger a realloc of the array's buffer. Python 3.0 (r30:67503, Dec 4 2008, 13:30:57) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from array import array >>> a = array('i', range(16)) >>> m = memoryview(a) >>> a.extend(array('i', range(48)) ... ) >>> m[:] = array('i', [0] * (len(m) // m.itemsize)) *** glibc detected *** python3.0: corrupted double-linked list: 0x0822c1f8 *** _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:24:01 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2008 23:24:01 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228605841.91.0.875704569867.issue1717@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, remove it in 3.0.1, provided that's released this year. Performance fixes are always fair game for bugfix releases. Please don't "fix" the what's new document (or undo the fix). I do hope cmp() was already undocumented elsewhere. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:24:57 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 06 Dec 2008 23:24:57 +0000 Subject: [issue4567] Registry key not set if unattended installation used In-Reply-To: <1228587246.7.0.370739440379.issue4567@psf.upfronthosting.co.za> Message-ID: <1228605897.9.0.930271033049.issue4567@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please be more explicit? What exact command line have you been using, and what exact registry do you think should have been set but wasn't? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:29:36 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 06 Dec 2008 23:29:36 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228606176.72.0.0984180864972.issue4449@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:33:47 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 06 Dec 2008 23:33:47 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228606427.7.0.934289668499.issue1717@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: critical -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:35:47 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 06 Dec 2008 23:35:47 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228606547.3.0.940892565274.issue4561@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:39:39 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 06 Dec 2008 23:39:39 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228606779.53.0.760787985615.issue4565@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:40:01 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 06 Dec 2008 23:40:01 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228606801.92.0.608387304042.issue1717@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Do the API functions PyObject_Compare() and PyObject_Cmp() also go away? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:41:59 2008 From: report at bugs.python.org (Stuart Axon) Date: Sat, 06 Dec 2008 23:41:59 +0000 Subject: [issue4567] Registry key not set if unattended installation used In-Reply-To: <1228605897.9.0.930271033049.issue4567@psf.upfronthosting.co.za> Message-ID: <838f4dc10812061540vd48c685wa3caf3573606bac@mail.gmail.com> Stuart Axon added the comment: Sure, no problem - sorry for the lack of detail... The windows installer (tested on 2.5.2) normally puts some values in the windows registry at: HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\ (where is the python version). Including the important one for me: InstallPath. The bug is in the installer msi, and will need to be fixed in whatever generates it, ideally the installpath should always be set. In order to install python silently, run msiexec python-2.5.2.msi /quiet This will install python to the default path (c:\python) and the registry values won't be set. I believe their probably set in the interactive part of the installation. 2008/12/6 Martin v. L?wis : > > Martin v. L?wis added the comment: > > Can you please be more explicit? What exact command line have you been > using, and what exact registry do you think should have been set but wasn't? > > ---------- > nosy: +loewis > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:46:32 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 06 Dec 2008 23:46:32 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228607192.95.0.666704057932.issue1717@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Do we also get rid of the tp_compare type slot? 6 types still use it, they should convert this to a tp_richcompare slot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:47:06 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 06 Dec 2008 23:47:06 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228607226.01.0.244345285826.issue1717@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes, tp_compare should go. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:49:18 2008 From: report at bugs.python.org (Martin Diers) Date: Sat, 06 Dec 2008 23:49:18 +0000 Subject: [issue4528] test_httpservers consistently fails on OS X using tarball, but not svn tag r30 In-Reply-To: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za> Message-ID: <1228607358.54.0.94772630761.issue4528@psf.upfronthosting.co.za> Changes by Martin Diers : ---------- title: test_httpservers consistently fails on OS X -> test_httpservers consistently fails on OS X using tarball, but not svn tag r30 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:56:01 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 06 Dec 2008 23:56:01 +0000 Subject: [issue4567] Registry key not set if unattended installation used In-Reply-To: <838f4dc10812061540vd48c685wa3caf3573606bac@mail.gmail.com> Message-ID: <493B102A.4080403@v.loewis.de> Martin v. L?wis added the comment: > In order to install python silently, run > > msiexec python-2.5.2.msi /quiet I'm puzzled. According to all msiexec documentation I could find, there is no /quiet option to msiexec (plus you also need to specify /i, according to the docs). I'll have to find out what this does first. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:58:05 2008 From: report at bugs.python.org (Stuart Axon) Date: Sat, 06 Dec 2008 23:58:05 +0000 Subject: [issue4567] Registry key not set if unattended installation used In-Reply-To: <493B102A.4080403@v.loewis.de> Message-ID: <838f4dc10812061556l422aa99ak532a575c00eb74f0@mail.gmail.com> Stuart Axon added the comment: If you type msiexec /? it pops a window with this text in it: Windows (R) Installer. V 3.01.4001.5512 msiexec /Option [Optional Parameter] Install Options Installs or configures a product /a Administrative install - Installs a product on the network /j [/t ] [/g ] Advertises a product - m to all users, u to current user Uninstalls the product Display Options /quiet Quiet mode, no user interaction /passive Unattended mode - progress bar only /q[n|b|r|f] Sets user interface level n - No UI b - Basic UI r - Reduced UI f - Full UI (default) /help Help information Restart Options /norestart Do not restart after the installation is complete /promptrestart Prompts the user for restart if necessary /forcerestart Always restart the computer after installation Logging Options /l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] i - Status messages w - Nonfatal warnings e - All error messages a - Start up of actions r - Action-specific records u - User requests c - Initial UI parameters m - Out-of-memory or fatal exit information o - Out-of-disk-space messages p - Terminal properties v - Verbose output x - Extra debugging information + - Append to existing log file ! - Flush each line to the log * - Log all information, except for v and x options /log Equivalent of /l* Update Options /update [;Update2.msp] Applies update(s) /uninstall [;Update2.msp] /package Remove update(s) for a product Repair Options /f[p|e|c|m|s|o|d|a|u|v] Repairs a product p - only if file is missing o - if file is missing or an older version is installed (default) e - if file is missing or an equal or older version is installed d - if file is missing or a different version is installed c - if file is missing or checksum does not match the calculated value a - forces all files to be reinstalled u - all required user-specific registry entries (default) m - all required computer-specific registry entries (default) s - all existing shortcuts (default) v - runs from source and recaches local package Setting Public Properties [PROPERTY=PropertyValue] Consult the Windows (R) Installer SDK for additional documentation on the command line syntax. Copyright (c) Microsoft Corporation. All rights reserved. Portions of this software are based in part on the work of the Independent JPEG Group. 2008/12/6 Martin v. L?wis : > > Martin v. L?wis added the comment: > >> In order to install python silently, run >> >> msiexec python-2.5.2.msi /quiet > > I'm puzzled. According to all msiexec documentation I could find, > there is no /quiet option to msiexec (plus you also need to specify > /i, according to the docs). I'll have to find out what this does > first. > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 01:06:48 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 00:06:48 +0000 Subject: [issue4569] Segfault when mutating a memoryview to an array.array In-Reply-To: <1228608408.03.0.674795963302.issue4569@psf.upfronthosting.co.za> Message-ID: <1228608408.03.0.674795963302.issue4569@psf.upfronthosting.co.za> New submission from Antoine Pitrou : >>> from array import array >>> a = array('i', range(16)) >>> m = memoryview(a) >>> m[:] = array('i', range(16)) Erreur de segmentation ---------- components: Interpreter Core messages: 77195 nosy: pitrou priority: critical severity: normal status: open title: Segfault when mutating a memoryview to an array.array type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 01:07:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 00:07:18 +0000 Subject: [issue4509] possible memoryview bug In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228608438.24.0.997376951372.issue4509@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The segfault happens even when the array is not being resized, I've opened a separate bug for it: #4509. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 01:09:29 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 00:09:29 +0000 Subject: [issue4509] bugs in array.array with exports (buffer protocol) In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228608569.61.0.0537814429417.issue4509@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The bytearray patch has been committed to 2.6, 2.7, 3.0, 3.1. Now the array.array problem remains. ---------- components: +Extension Modules -Interpreter Core stage: patch review -> needs patch title: possible memoryview bug -> bugs in array.array with exports (buffer protocol) versions: +Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 01:12:11 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 00:12:11 +0000 Subject: [issue4509] bugs in array.array with exports (buffer protocol) In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228608731.2.0.998890739074.issue4509@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sorry, typo: the segfault issue is #4569. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 01:23:12 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 07 Dec 2008 00:23:12 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228609392.36.0.353480655221.issue1717@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: tp_richcompare is less convenient to implement than tp_compare. See for example how in Objects/longobject.c, long_richcompare() calls long_compare() *and* a helper method Py_CmpToRich. Likewise, turning __cmp__ into the whole set of __lt__, __le__, __ge__, __gt__, __eq__, __ne__ methods (did I forget one?) is tedious. I'm not talking for my own code, but for the python standard objects and library (and the Demo directory) where I'm currently trying to remove __cmp__ and tp_compare. I am not far to write a hack (mixin, metaclass) to inject rich comparison functions based on a single __cmp__ function. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:03:35 2008 From: report at bugs.python.org (mike bayer) Date: Sun, 07 Dec 2008 01:03:35 +0000 Subject: [issue998998] pickle bug - recursively memoizing class? Message-ID: <1228611815.68.0.0498927683201.issue998998@psf.upfronthosting.co.za> mike bayer added the comment: This bug can be reproduced very easily: import pickle class MyClass(object): pass m = MyClass() m2 = MyClass() s = set([m]) m.foo = set([m2]) m2.foo = s print pickle.dumps(s) This bug is critical as the pure-python pickle module is required when trying to remove warnings in -3 mode with Python 2.6, which is something that will be very common in the near future. It's easily reproducible with simplistic object cycles like that of the above, in 2.5, 2.6 and 3.0 at least. ---------- nosy: +zzzeek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:10:18 2008 From: report at bugs.python.org (John Marter) Date: Sun, 07 Dec 2008 01:10:18 +0000 Subject: [issue4570] Bad example in set tutorial In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za> Message-ID: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za> New submission from John Marter : On http://docs.python.org/3.0/tutorial/datastructures.html#sets there is the following section in the section on sets >>> basket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'} >>> print(basket) {'orange', 'bananna', 'pear', 'apple'} >>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana'] >>> fruit = set(basket) # create a set without duplicates >>> fruit {'orange', 'pear', 'apple', 'banana'} The third command should be an assignment to basket rather than fruit. ---------- assignee: georg.brandl components: Documentation messages: 77201 nosy: georg.brandl, jmarter severity: normal status: open title: Bad example in set tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:12:19 2008 From: report at bugs.python.org (John Marter) Date: Sun, 07 Dec 2008 01:12:19 +0000 Subject: [issue4570] Bad example in set tutorial In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za> Message-ID: <1228612339.42.0.914768948396.issue4570@psf.upfronthosting.co.za> John Marter added the comment: Also, I see banana is misspelled on the first output line (line 3). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:14:25 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 07 Dec 2008 01:14:25 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228612465.65.0.864182874226.issue1717@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Either take out the C-API functions or re-define them as: lambda a, b: (a > b) - (a < b) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:21:43 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 07 Dec 2008 01:21:43 +0000 Subject: [issue4570] Bad example in set tutorial In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za> Message-ID: <1228612903.13.0.234905535914.issue4570@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed r67624. ---------- nosy: +rhettinger resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:41:48 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 07 Dec 2008 01:41:48 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228597621.54.0.49939567903.issue4483@psf.upfronthosting.co.za> Message-ID: <18747.10702.304464.831943@montanaro-dyndns-org.local> Skip Montanaro added the comment: Roumen> may be patch is not applied correctly : Roumen> http://svn.python.org/view/python/trunk/setup.py?rev=67614&view=auto Roumen> libraries = gdbm_libs ) ) Roumen> ? exts.append( Extension('dbm', ['dbmmodule.c'], Roumen> ? define_macros=[('HAVE_GDBM_NDBM_H',None)], Roumen> ? libraries = ['gdbm'] ) ) Roumen> elif db_incs is not None: Yeah, muffed it. I should have a fix checked in shortly. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:50:55 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 07 Dec 2008 01:50:55 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228614655.25.0.390851635939.issue1717@psf.upfronthosting.co.za> Raymond Hettinger added the comment: r67627 : complete the dedocumenting of cmp(). Amaury, I have a non-metaclass solution for you. Will post on ASPN. It uses a class decorator to sniff-out *any* defined rich ordering comparisons and the automatically fills-in those that are missing. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:58:15 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 07 Dec 2008 01:58:15 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228615095.99.0.901311408397.issue1717@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, the tp_compare slot in setobject.c serves only say the cmp() isn't defined. It can be ripped-out straight-away. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 03:40:11 2008 From: report at bugs.python.org (jeff deifik) Date: Sun, 07 Dec 2008 02:40:11 +0000 Subject: [issue4571] write to stdout in binary mode - is it possible? In-Reply-To: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za> Message-ID: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za> New submission from jeff deifik : I have a program that needs to output binary data to stdout. I don't want to convert it to a string. for example something like sys.stdout.write('0o377') to write a byte with all the bits turned on. When I try this, I get an error like: sys.stdout.write(data) File "/usr/local/lib/python3.0/io.py", line 1484, in write s.__class__.__name__) TypeError: can't write bytes to text stream I know I can open a file in 'wb' mode and write to it, but what I want to do is somehow switch the mode of stdout to 'wb' mode. I read lots of python 3 documentation, as well as searched without finding a way. ---------- components: Interpreter Core messages: 77208 nosy: lopgok severity: normal status: open title: write to stdout in binary mode - is it possible? type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 04:07:26 2008 From: report at bugs.python.org (gumpy) Date: Sun, 07 Dec 2008 03:07:26 +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: <1228619246.7.0.33647353236.issue1028@psf.upfronthosting.co.za> gumpy added the comment: This problem exists for me on Ubuntu8.04 with both tk/tcl8.4.16 and 8.5. ---------- nosy: +gumpy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 04:15:00 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 07 Dec 2008 03:15:00 +0000 Subject: [issue4571] write to stdout in binary mode - is it possible? In-Reply-To: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za> Message-ID: <1228619700.59.0.56643958207.issue4571@psf.upfronthosting.co.za> Benjamin Peterson added the comment: You can write to the underlying raw stream: sys.stdout.buffer.write(b'abc') ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 04:32:13 2008 From: report at bugs.python.org (Craig Holmquist) Date: Sun, 07 Dec 2008 03:32:13 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228620733.99.0.134856979495.issue4566@psf.upfronthosting.co.za> Craig Holmquist added the comment: I understand the rationale behind #4120, but it seems like it only helps a narrow set of applications, namely "applications that link dynamically with the same version of MSVCR90 as Python and that bundle the MSVCR90 DLL and that can't install the VS2008 redist". In 2.6.1 those apps don't have to install the VS2008 redist, but every other app needs to either bundle the runtime DLLs (as a private assembly) or use the manifest workaround I described above, even if the VS2008 redist is installed on the system. The 2.6.0 behavior - requiring the VS2008 redist to be installed - is hardly perfect (to put it mildly), but in my opinion it's more obvious and straightforward, and more consistent with the behavior of other Windows software. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 05:23:13 2008 From: report at bugs.python.org (I. Stead) Date: Sun, 07 Dec 2008 04:23:13 +0000 Subject: [issue4049] IDLE does not open too In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za> Message-ID: <1228623793.64.0.0725306351136.issue4049@psf.upfronthosting.co.za> I. Stead added the comment: This still seems to be happening in python 3.0 as well. Here is the output from >1. open cmd.exe >2. cd \python26 >3. python.exe Lib\idlelib\idle.py C:\Program Files\Python>python.exe Lib\idlelib\idle.py Traceback (most recent call last): File "Lib\idlelib\idle.py", line 22, in idlelib.PyShell.main() File "C:\Program Files\Python\lib\idlelib\PyShell.py", line 1385, in main shell = flist.open_shell() File "C:\Program Files\Python\lib\idlelib\PyShell.py", line 276, in open_shell self.pyshell = PyShell(self) File "C:\Program Files\Python\lib\idlelib\PyShell.py", line 800, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Program Files\Python\lib\idlelib\OutputWindow.py", line 16, in __init __ EditorWindow.__init__(self, *args) File "C:\Program Files\Python\lib\idlelib\EditorWindow.py", line 243, in __ini t__ self.update_recent_files_list() File "C:\Program Files\Python\lib\idlelib\EditorWindow.py", line 761, in updat e_recent_files_list rf_file = open(self.recent_files_path, 'w') File "C:\Program Files\Python\lib\io.py", line 278, in __new__ return open(*args, **kwargs) File "C:\Program Files\Python\lib\io.py", line 222, in open closefd) File "C:\Program Files\Python\lib\io.py", line 615, in __init__ _fileio._FileIO.__init__(self, name, mode, closefd) IOError: [Errno 13] Permission denied: 'C:\\Users\\Isaac\\.idlerc\\recent-files. lst' ---------- nosy: +VitP versions: +Python 3.0 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 05:44:23 2008 From: report at bugs.python.org (gumpy) Date: Sun, 07 Dec 2008 04:44:23 +0000 Subject: [issue4572] add SEEK_* values to io and/or io.IOBase In-Reply-To: <1228625063.64.0.370686457231.issue4572@psf.upfronthosting.co.za> Message-ID: <1228625063.64.0.370686457231.issue4572@psf.upfronthosting.co.za> New submission from gumpy : Currently io.IOBase.seek(offset[, whence]) uses magic numbers for the second argument. Since this is essentially identical the C function fseek I think adding the same "constants" that C uses (SEEK_SET=0, SEEK_CUR=1, SEEK_END=2) may be worth considering. These values could be added to the global scope in the io module: f = io.open('foo', 'rb') f.seek(0, io.SEEK_END) If added to the io.IOBase class then I believe they'd be accessible without importing io: f = open('foo', 'rb') f.seek(0, f.SEEK_END) ---------- components: Library (Lib) messages: 77213 nosy: gumpy severity: normal status: open title: add SEEK_* values to io and/or io.IOBase type: feature request versions: Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 06:02:58 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sun, 07 Dec 2008 05:02:58 +0000 Subject: [issue4559] Whats new recommendation error In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za> Message-ID: <1228626178.86.0.736570871642.issue4559@psf.upfronthosting.co.za> Lennart Regebro added the comment: Fair enough, but I still think we can come up with a better example that requires more contortions than "print", which doesn't. I think a good example of contortions is binary file data, which has two different types in 2.6 and 3.0. Also making sure that you use iterators all the time when using large sets of data can get quite contorted. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 09:03:07 2008 From: report at bugs.python.org (Winfried Plappert) Date: Sun, 07 Dec 2008 08:03:07 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228636987.82.0.52128891382.issue4565@psf.upfronthosting.co.za> Changes by Winfried Plappert : ---------- nosy: +wplappert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 09:03:46 2008 From: report at bugs.python.org (Winfried Plappert) Date: Sun, 07 Dec 2008 08:03:46 +0000 Subject: [issue3476] BufferedWriter not thread-safe In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za> Message-ID: <1228637026.22.0.907087639291.issue3476@psf.upfronthosting.co.za> Changes by Winfried Plappert : ---------- nosy: +wplappert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 09:04:56 2008 From: report at bugs.python.org (Winfried Plappert) Date: Sun, 07 Dec 2008 08:04:56 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228637096.8.0.849078405712.issue4561@psf.upfronthosting.co.za> Changes by Winfried Plappert : ---------- nosy: +wplappert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 09:16:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 07 Dec 2008 08:16:18 +0000 Subject: [issue4571] write to stdout in binary mode - is it possible? In-Reply-To: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za> Message-ID: <1228637778.48.0.322521716174.issue4571@psf.upfronthosting.co.za> Georg Brandl added the comment: Is that an official way? If yes, it needs to be documented. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 09:17:57 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Sun, 07 Dec 2008 08:17:57 +0000 Subject: [issue4573] zsh-style subpattern matching for fnmatch/glob In-Reply-To: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za> Message-ID: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za> New submission from Erick Tryzelaar : As I mentioned on python-ideas, I my project needs to extend fnmatch to support zsh-style globbing, where you can use brackets to designate subexpressions. Say you had a directory structure like this: foo/ foo.ext1 foo.ext2 bar/ foo.ext1 foo.ext2 The subexpressions will let you do patterns like this: >>> glob.glob('foo/foo.{ext1,ext2}') ['foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('foo/foo.ext{1,2}') ['foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('{foo,bar}') ['bar', 'foo'] >>> glob.glob('{foo,bar}/foo*') ['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('{foo,bar}/foo.{ext*}') ['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('{f?o,b?r}/foo.{ext*}') ['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2'] Would this be interesting to anyone else? It would unfortunately break fnmatch since it currently treats {} as ordinary characters. It'd be easy to work around that by adding a flag or using a different function name though. Anyway, here's the patch against the head of py3k. ---------- components: Library (Lib) files: zsh-fnmatch.diff keywords: patch messages: 77216 nosy: erickt severity: normal status: open title: zsh-style subpattern matching for fnmatch/glob type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file12259/zsh-fnmatch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 10:09:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 07 Dec 2008 09:09:14 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228620733.99.0.134856979495.issue4566@psf.upfronthosting.co.za> Message-ID: <493B92B4.5040104@v.loewis.de> Martin v. L?wis added the comment: > I understand the rationale behind #4120, but it seems like it only helps > a narrow set of applications, namely "applications that link dynamically > with the same version of MSVCR90 as Python and that bundle the MSVCR90 > DLL and that can't install the VS2008 redist". This is not a narrow set, though. It includes all the applications that use py2exe and friends to create stand-alone applications. This case absolutely must be supported. > The 2.6.0 behavior - requiring the VS2008 redist to be installed - is > hardly perfect (to put it mildly), but in my opinion it's more obvious > and straightforward, and more consistent with the behavior of other > Windows software. Python has a long tradition of supporting "xcopy deployment". I don't want Microsoft to dictate that we stop supporting that. I find the need to have end-users install the CRT redist particularly unacceptable. I don't quite understand this issue yet. python26.dll is linked with a manifest. Isn't that good enough? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 11:28:39 2008 From: report at bugs.python.org (=?utf-8?q?Sever_B=C4=83ne=C8=99iu?=) Date: Sun, 07 Dec 2008 10:28:39 +0000 Subject: [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za> Message-ID: <1228645719.26.0.587186489049.issue4263@psf.upfronthosting.co.za> Sever B?ne?iu added the comment: Christian, if the patch looks good to you I think now it's a good time to commit it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 12:00:35 2008 From: report at bugs.python.org (John Machin) Date: Sun, 07 Dec 2008 11:00:35 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> New submission from John Machin : Problem in the newline handling in io.py, class IncrementalNewlineDecoder, method decode. It reads text files in 128- byte chunks. Converting CR LF to \n requires special case handling when '\r' is detected at the end of the decoded chunk in case there's an LF at the start of the next chunk. It prepends b'\r' (only 1 byte) to the next chunk's raw bytes and decodes that. But \r in UTF-16 takes 2 bytes; we are now 1 byte out of kilter and various failures are possible (including silently producing garbage output from a truncated file with an odd number of bytes). The attached script illustrates the problems. ---------- components: Interpreter Core files: py30cr64bug.py messages: 77219 nosy: sjmachin severity: normal status: open title: reading UTF16-encoded text file crashes if \r on 64-char boundary type: crash versions: Python 3.0 Added file: http://bugs.python.org/file12260/py30cr64bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 12:43:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 11:43:09 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228650189.93.0.690259186761.issue4574@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 13:19:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 12:19:27 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228652367.4.0.117093565247.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: +1 for a speedy removal of cmp and tp_compare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 13:35:14 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 07 Dec 2008 12:35:14 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1228653314.07.0.847090400192.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: I plan to change my patch to come back to a method (x.numbits()) because other integer implementations like Decimal may be slower. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 13:36:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 07 Dec 2008 12:36:56 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228653416.59.0.405899832612.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: We shouldn't remove the tp_compae slot in 3.0. That's going to break too much 3rd party software. Instead of removing it, a deprecation warning should be printed when the slot isn't 0. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 13:42:44 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 12:42:44 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> New submission from Mark Dickinson : In issue 4506, Skip reported that test_cmath fails on Solaris 10/x86 for 3.0. If my guesses are correct, it probably fails on all x86 systems that (a) use the x87 coprocessor for floating-point (as opposed to using SSE2, for example), and (b) don't have isinf available. Problem: Py_IS_INFINITY is applied to a floating-point value sitting in an 80-bit x87 register; that value is not infinity, but after moving it back to memory (and hence rounding from 80-bit extended precision to 64-bit double precision with its smaller exponent range) it becomes infinity. Solution: Add a macro to pymath.h that forces rounding from extended precision to double precision; apply this macro *before* calling Py_IS_INFINITY. See attached patch for an example. Problem: After applying the attached patch to the py3k branch, the cmath module fails to build. On OS X 10.5, I get: running build_ext building 'cmath' extension gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386- 3.1/Users/dickinsm/python_source/py3k/Modules/cmathmodule.o - L/usr/local/lib -o build/lib.macosx-10.3-i386-3.1/cmath.so *** WARNING: renaming "cmath" since importing it failed: dlopen(build/lib.macosx-10.3-i386-3.1/cmath.so, 2): Symbol not found: _Py_force_to_memory Referenced from: /Users/dickinsm/python_source/py3k/build/lib.macosx- 10.3-i386-3.1/cmath.so Expected in: dynamic lookup Solution: ??? Christian, as the architect of pymath.h, do you have any ideas what I'm doing wrong? Or comments on the patch in general? What do I need to do to make Py_force_to_memory visible to extension modules? ---------- assignee: marketdickinson components: Extension Modules files: force_to_memory.patch keywords: patch messages: 77223 nosy: christian.heimes, marketdickinson, skip.montanaro priority: high severity: normal status: open title: Py_IS_INFINITY defect causes test_cmath failure on x86 type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12261/force_to_memory.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 13:50:17 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 12:50:17 +0000 Subject: [issue4506] 3.0 make test failures on Solaris 10 In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local> Message-ID: <1228654217.42.0.360531083283.issue4506@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks, Skip. It looks like the top priority is fixing Py_IS_INFINITY, then (still assuming that I'm not barking up entirely the wrong tree). I've opened issue 4575 for the Py_IS_INFINITY fix. I'll look at the changes to AC_CHECK_FUNCS, too. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 14:08:57 2008 From: report at bugs.python.org (Kandalintsev Alexandre) Date: Sun, 07 Dec 2008 13:08:57 +0000 Subject: [issue4576] "Defining new types" little outdated In-Reply-To: <1228655337.64.0.961610500234.issue4576@psf.upfronthosting.co.za> Message-ID: <1228655337.64.0.961610500234.issue4576@psf.upfronthosting.co.za> New submission from Kandalintsev Alexandre : Hello! It's need to little update "Defining new types" documentation section in py3.0 and py3.1: - self->ob_type->tp_free((PyObject*)self); + Py_TYPE(self)->tp_free((PyObject *)self); ---------- assignee: georg.brandl components: Documentation messages: 77225 nosy: exe, georg.brandl severity: normal status: open title: "Defining new types" little outdated versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 14:11:45 2008 From: report at bugs.python.org (Kandalintsev Alexandre) Date: Sun, 07 Dec 2008 13:11:45 +0000 Subject: [issue4535] Build / Test Py3K failed on Ubuntu 8.10 In-Reply-To: <1228423046.58.0.110673745829.issue4535@psf.upfronthosting.co.za> Message-ID: <1228655505.78.0.79333331168.issue4535@psf.upfronthosting.co.za> Kandalintsev Alexandre added the comment: Rob, could you repeat this test on trunk version of python? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 15:09:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 07 Dec 2008 14:09:35 +0000 Subject: [issue4576] "Defining new types" little outdated In-Reply-To: <1228655337.64.0.961610500234.issue4576@psf.upfronthosting.co.za> Message-ID: <1228658975.51.0.826134660938.issue4576@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r67632. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 15:20:56 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 07 Dec 2008 14:20:56 +0000 Subject: [issue4573] zsh-style subpattern matching for fnmatch/glob In-Reply-To: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za> Message-ID: <1228659656.85.0.947924105612.issue4573@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 15:58:28 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 07 Dec 2008 14:58:28 +0000 Subject: [issue4571] write to stdout in binary mode - is it possible? In-Reply-To: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za> Message-ID: <1228661908.29.0.443054316437.issue4571@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Documented in r67365. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 16:49:01 2008 From: report at bugs.python.org (jeff deifik) Date: Sun, 07 Dec 2008 15:49:01 +0000 Subject: [issue4571] write to stdout in binary mode - is it possible? In-Reply-To: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za> Message-ID: <1228664941.47.0.459984387954.issue4571@psf.upfronthosting.co.za> jeff deifik added the comment: I don't consider sys.stdout.buffer.write(b'abc') to be an acceptable solution. There are many programs that need to produce binary output with standard output. Consider uudecode and similar programs. There needs to be a standard, portable, documented way to put stdout into binary mode in order to write binary output. For example, all the flavors of the print command need to be able to send binary data to standard output. I don't have a problem changing open statements to support binary file i/o, but I do have a problem changing every print or write statement in order to support binary file i/o. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 16:51:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 07 Dec 2008 15:51:11 +0000 Subject: [issue4571] write to stdout in binary mode - is it possible? In-Reply-To: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za> Message-ID: <1228665071.13.0.442978603575.issue4571@psf.upfronthosting.co.za> Christian Heimes added the comment: switch to binary mode >>> sys.stdout = sys.stdout.buffer switch back >>> sys.stdout = sys.__stdout__ ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 17:11:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 07 Dec 2008 16:11:24 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228666284.12.0.238083531832.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is a longer patch that removes cmp, PyObject_Compare and cmpfunc. The slots has been renamed to tp_reserved. If the slot is used by a type an exception is raised to notify the user about possible issues. Missing: * fix unit tests * add error checks to PyObject_RichCompareBool calls * Remove/replace the last PyUnicode Compare ASII function Added file: http://bugs.python.org/file12262/remove_cmp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 17:26:08 2008 From: report at bugs.python.org (Craig Holmquist) Date: Sun, 07 Dec 2008 16:26:08 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228667168.73.0.491342290444.issue4566@psf.upfronthosting.co.za> Craig Holmquist added the comment: > I don't quite understand this issue yet. python26.dll is linked with > a manifest. Isn't that good enough? Apparently not, at least in my testing. It seems that if a DLL is loaded, Windows will try to resolve its dependencies by looking at that DLL's own manifest; if that fails, Windows will try to resolve them by looking at the EXE's manifest. It won't check other DLLs. From the loader's perspective, it seems like there's no "tree" of DLLs, it's just "EXE loads DLL, EXE loads DLL", even if the loading code is actually in one of the DLLs. I guess I'm more concerned about applications like Apache that only use Python through an external module or plugin; there's no reason the Apache developers would be expected to make this kind of change with the manifests and everything, much less any commercial, closed-source app (say, an IDE or editor that has plugins for several scripting languages). Also, the manifest trick I described as a workaround was only as simple as it was in this case because httpd.exe didn't have any manifest at all; if it already had an internal manifest, working-around this would have been much more gruesome. I understand, though, the value of "xcopy deployment", and I realize that having some means of doing that is better than none at all. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 18:20:07 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Sun, 07 Dec 2008 17:20:07 +0000 Subject: [issue4577] distutils: -3 warnings (apply) In-Reply-To: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za> Message-ID: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za> New submission from Sebastian Rittau : The attached patch removes all instances of the deprecated "apply" function from distutils and thereby fixes warnings when run with -3. ---------- components: Distutils files: distutils.diff keywords: patch messages: 77233 nosy: srittau severity: normal status: open title: distutils: -3 warnings (apply) versions: Python 2.6 Added file: http://bugs.python.org/file12263/distutils.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 18:22:22 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Sun, 07 Dec 2008 17:22:22 +0000 Subject: [issue4577] distutils: -3 warnings (apply) In-Reply-To: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za> Message-ID: <1228670542.05.0.0815237445888.issue4577@psf.upfronthosting.co.za> Sebastian Rittau added the comment: Oops, missed a closing parenthesis. Added file: http://bugs.python.org/file12264/distutils.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 18:22:28 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Sun, 07 Dec 2008 17:22:28 +0000 Subject: [issue4577] distutils: -3 warnings (apply) In-Reply-To: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za> Message-ID: <1228670548.44.0.938837932134.issue4577@psf.upfronthosting.co.za> Changes by Sebastian Rittau : Removed file: http://bugs.python.org/file12263/distutils.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 18:26:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 17:26:26 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228670786.58.0.128545551957.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'll work on fixing the unit tests if that's helpful. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 18:29:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 07 Dec 2008 17:29:46 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228670986.73.0.551716565921.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you fix the decimal module and tests? You know more about the module than me. I'm half through most of the others modules. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 18:31:23 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 17:31:23 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228671083.6.0.424175818847.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: Decimal fixes Added file: http://bugs.python.org/file12265/remove_cmp_decimal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 18:35:47 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Sun, 07 Dec 2008 17:35:47 +0000 Subject: [issue4578] compiler: -3 warnings In-Reply-To: <1228671347.68.0.444266504353.issue4578@psf.upfronthosting.co.za> Message-ID: <1228671347.68.0.444266504353.issue4578@psf.upfronthosting.co.za> New submission from Sebastian Rittau : The attached patch replaces all instances of "x.has_key(k)" method calls by "k in x". It also replaces one call to parser.ast2tuple by parser.st2tuple. This removes deprecation warnings when running in -3 mode. ---------- components: Library (Lib) files: compiler.diff keywords: patch messages: 77238 nosy: srittau severity: normal status: open title: compiler: -3 warnings versions: Python 2.6 Added file: http://bugs.python.org/file12266/compiler.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:13:25 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 07 Dec 2008 18:13:25 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228673605.24.0.688484964694.issue1717@psf.upfronthosting.co.za> Changes by Christian Heimes : Removed file: http://bugs.python.org/file12262/remove_cmp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:15:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 07 Dec 2008 18:15:11 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228673711.25.0.596706309481.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: I've integrated Mark's patch and fixed more tests. Who wants to pick it up from here? Added file: http://bugs.python.org/file12267/remove_cmp2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:47:02 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 18:47:02 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228675622.11.0.546828908971.issue4558@psf.upfronthosting.co.za> Roumen Petrov added the comment: :-( the last my comment is incomplete : work for me after "minimal patch" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:55:53 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 18:55:53 +0000 Subject: [issue3754] minimal cross-compilation support for configure In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1228676153.5.0.553793037406.issue3754@psf.upfronthosting.co.za> Roumen Petrov added the comment: The support for *-*mingw* host is enhanced to native msys environment. This include check for device file /dev/ptmx. The MSYS report that file exist. As the check is skipped on mingw* host os now cugwin environment can be used too. Also check libintl is skipped for mingw as the native build don't use it. Added file: http://bugs.python.org/file12268/python-trunk-CROSS.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 20:06:32 2008 From: report at bugs.python.org (Mark Florisson) Date: Sun, 07 Dec 2008 19:06:32 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> New submission from Mark Florisson : >>> f = os.fdopen(os.open('spam!', os.O_TRUNC|os.O_CREAT|os.O_RDWR), 'w') >>> f.read() '' >>> f.readline() Traceback (most recent call last): File "", line 1, in IOError: [Errno 9] Bad file descriptor >>> f.write("spamspamhihi") >>> f.read() '' >>> f.seek(0) >>> f.read() Traceback (most recent call last): File "", line 1, in IOError: [Errno 9] Bad file descriptor This is very strange behaviour. First, .read() succeeds, and .readline() fails, but after writing and seeking, .read() also fails. In python3, both read and readline fail, but with different exceptions: >>> f = os.fdopen(os.open('spam!', os.O_TRUNC|os.O_CREAT|os.O_RDWR), 'w') >>> f.read() Traceback (most recent call last): File "", line 1, in File "/home/mark/source/code/_python-3.0/Lib/io.py", line 1718, in read decoder.decode(self.buffer.read(), final=True)) File "/home/mark/source/code/_python-3.0/Lib/io.py", line 668, in read self._unsupported("read") File "/home/mark/source/code/_python-3.0/Lib/io.py", line 327, in _unsupported (self.__class__.__name__, name)) io.UnsupportedOperation: BufferedWriter.read() not supported >>> f.readline() Traceback (most recent call last): File "", line 1, in File "/home/mark/source/code/_python-3.0/Lib/io.py", line 1807, in readline while self._read_chunk(): File "/home/mark/source/code/_python-3.0/Lib/io.py", line 1554, in _read_chunk input_chunk = self.buffer.read1(self._CHUNK_SIZE) AttributeError: 'BufferedWriter' object has no attribute 'read1' In my opinion, all operations, in all python versions, should fail like readline in the first example: IOError: [Errno 9] Bad file descriptor ---------- messages: 77242 nosy: eggy severity: normal status: open title: .read() and .readline() differ in failing type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 20:22:20 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 19:22: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: <1228677740.93.0.959224312465.issue3871@psf.upfronthosting.co.za> Roumen Petrov added the comment: The new patch is attached. Now the patch allow native build for mingw* host OS. The build id tested in MSYS environment. The issue title is updated to reflect this. The main changes: - native build require four more build-in modules (_functools, operator ,_locale, _winreg) otherwise setup.py fail to load; - changes in distutils for python 2.6+. The previous patch work on python 2.4 run in cross environment; - don't build with libintl; - use long double functions ldexp() atan2() from mingwex library as replacement for buggy msvcrt implementation. The new patch don't include changes related to issue 4288 (see also issue 4279). ---------- title: cross building python for mingw32 with distutils -> cross and native build of python for mingw32 with distutils Added file: http://bugs.python.org/file12269/python-trunk-MINGW.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 20:23:22 2008 From: report at bugs.python.org (Mark Florisson) Date: Sun, 07 Dec 2008 19:23:22 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228677802.33.0.953577048634.issue4579@psf.upfronthosting.co.za> Mark Florisson added the comment: Actually, I wouldn't expect it to fail like that, because it's not a bad file descriptor, it's an actual that doesn't agree with the (userspace) file mode. What I'd expect is probably a TypeError. Although an IOError, with a different message, wouldn't be totally inappropriate either. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 20:24:03 2008 From: report at bugs.python.org (Mark Florisson) Date: Sun, 07 Dec 2008 19:24:03 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228677843.26.0.166932903556.issue4579@psf.upfronthosting.co.za> Mark Florisson added the comment: s/actual/operation/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:07:25 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 20:07:25 +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: <1228680445.06.0.793476512173.issue3871@psf.upfronthosting.co.za> Roumen Petrov added the comment: About the regression test results test. The result from 2008-11-29 is: 306 tests OK. 1 test failed: test_sundry 54 tests skipped: .... Those skips are all expected on win32. To get those results you mingwex library has to contain fixes for two issues(see mingw32 bug tracker). - 2136252 (fixed in trunk): c99, printf and float zero precision; - 2117590 (pending): correction of function asinh - inverse hyperbolic sine. For the python regression tests copysign is enough. About "test_sundry" depend on _msi module. I don't plan to work on mingw build for _msi module. Note that mingw build is with OS system default msvcrt so there is no "Assembly Hell". The trunk from 2008-12-07 fail in addition on test_anydbm, test_bsddb and test_whichdb. No idea what is wrong. It seems to that break is related to updates. As example dbm module still fail to build on my linux. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:27:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 20:27:12 +0000 Subject: [issue4569] Segfault when mutating a memoryview to an array.array In-Reply-To: <1228608408.03.0.674795963302.issue4569@psf.upfronthosting.co.za> Message-ID: <1228681632.89.0.554921003359.issue4569@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed in r67650 and r67651. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:31:47 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 20:31:47 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The problem is with the `shape` member which doesn't get recalculated as it should when instantiating a memoryview slice: >>> a = array('i', range(10)) >>> m = memoryview(a)[2:8] >>> a array('i', [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) >>> m[:] = array('i', range(6)) Traceback (most recent call last): File "", line 1, in ValueError: cannot modify size of memoryview object >>> len(m) 6 >>> m.shape (10,) An additional problem is that `shape` is a pointer to an array of integers, and we don't know how to reallocate it. ---------- components: Interpreter Core messages: 77248 nosy: pitrou priority: high severity: normal stage: test needed status: open title: slicing of memoryviews when itemsize != 1 is wrong type: behavior versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:32:43 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2008 20:32:43 +0000 Subject: [issue4509] bugs in array.array with exports (buffer protocol) In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228681963.26.0.0745590235415.issue4509@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Found another bug with memoryview and arrays in #4580. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:33:14 2008 From: report at bugs.python.org (Aaron Gallagher) Date: Sun, 07 Dec 2008 20:33:14 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228681994.49.0.927794167114.issue4579@psf.upfronthosting.co.za> Aaron Gallagher added the comment: I can't reproduce this on python 2.5.1, 2.5.2, or 2.6.0 on Mac OS 10.5.4. Both .read() and .readline() raise an EBADF IOError. 3.0.0 fails in the same way. ---------- nosy: +habnabit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:41:17 2008 From: report at bugs.python.org (Leger) Date: Sun, 07 Dec 2008 20:41:17 +0000 Subject: [issue4581] failed to import module from lib-dynload In-Reply-To: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za> Message-ID: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za> New submission from Leger : I test PY3K.final under Debian/Lenny. - Install steps "Configure, make, make test, make install don't generate errors for the modules in "lib-dynload". - "/usr/lib/python3.0/lib-dynload", contain modules (time.so, math.so, ...) - print(sys.path) = ['', '/usr/lib/python3.0', '/home/fred/python', '/usr/lib/python3.0/lib/python30.zip', '/usr/lib/python3.0/lib/python3.0', '/usr/lib/python3.0/lib/python3.0/plat-linux2', '/usr/lib/python3.0/lib/python3.0/lib-dynload'] - When I launch "python3.0" no error is generate, but when I try to import modules in "lib-dynload" : Python 3.0 (r30:67503, Dec 7 2008, 19:22:34) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time Traceback (most recent call last): File "", line 1, in ImportError: No module named time [33620 refs] ---------- components: Library (Lib) messages: 77251 nosy: legerf severity: normal status: open title: failed to import module from lib-dynload type: resource usage versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:48:39 2008 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 07 Dec 2008 20:48:39 +0000 Subject: [issue4582] type of __builtins__ changes if in main module or not In-Reply-To: <1228682919.53.0.035672589956.issue4582@psf.upfronthosting.co.za> Message-ID: <1228682919.53.0.035672589956.issue4582@psf.upfronthosting.co.za> New submission from Neal Norwitz : This happens on 2.4 and 3.0, probably all versions: When running this simple program (save to a file): print(type(__builtins__)) __import__(__file__.split('/')[-1][:-3]) I get: I would expect the type to be consistent regardless of whether executing the main module or from the imported module. I haven't looked into why this is happening or if it makes sense. It was unexpected. ---------- components: Interpreter Core messages: 77252 nosy: nnorwitz severity: normal status: open title: type of __builtins__ changes if in main module or not type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:53:29 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 07 Dec 2008 20:53:29 +0000 Subject: [issue4581] failed to import module from lib-dynload In-Reply-To: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za> Message-ID: <1228683209.7.0.189387961758.issue4581@psf.upfronthosting.co.za> Martin v. L?wis added the comment: How did you run configure? What is sys.exec_prefix? '/usr/lib/python3.0/lib/python3.0/lib-dynload' should not be on sys.path, but '/usr/lib/python3.0/lib-dynload' should be. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:57:08 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 07 Dec 2008 20:57:08 +0000 Subject: [issue4582] type of __builtins__ changes if in main module or not In-Reply-To: <1228682919.53.0.035672589956.issue4582@psf.upfronthosting.co.za> Message-ID: <1228683428.4.0.278504821663.issue4582@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is documented, intentional behavior: http://docs.python.org/library/__builtin__.html?highlight=__builtins__ ---------- nosy: +loewis resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:03:54 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 21:03:54 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228683834.9.0.181577687093.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: remove_cmp3.patch adds to Christian's patch to fix 6 more test_failures: (test_distutils, test_kqueue, test_list, test_sort, test_sqlite, test_userlist). On OS X, the only remaining test failure is test_unittest.py. Added file: http://bugs.python.org/file12270/remove_cmp3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:07:53 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 21:07:53 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228684073.44.0.102970903142.issue4483@psf.upfronthosting.co.za> Roumen Petrov added the comment: I'm not sure that recent commits in trunk are correct. Please confirm that build of dbm module with "Berkeley DB" is deprecated. Note that exist another module gdbm[gdbmmodule.c]. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:10:24 2008 From: report at bugs.python.org (Krzysztof Pawlik) Date: Sun, 07 Dec 2008 21:10:24 +0000 Subject: [issue1490929] urllib.retrieve's reporthook called with non-helpful value Message-ID: <1228684224.16.0.421081543659.issue1490929@psf.upfronthosting.co.za> Krzysztof Pawlik added the comment: Attached patch adds new argument: progresshook - it will be passed two arguments: count of downloaded bytes and total file size (or -1 if it's not available). Introducing new argument instead of modifying reporthook maintains backwards compatibility, also allows removal of reporthook at one point in the future. This patch is against r30 SVN tag. ---------- keywords: +patch nosy: +nelchael Added file: http://bugs.python.org/file12271/progresshook.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:26:46 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 21:26:46 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228685206.0.0.0371028186692.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: About unittest: unittest.TestLoader has an attribute "sortTestMethodsUsing", which it expects to be an old-style comparison. Should this attribute be updated (and renamed?) to expect a key function instead, or left as is? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:29:34 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 21:29:34 +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: <1228685374.62.0.883286390717.issue3871@psf.upfronthosting.co.za> Roumen Petrov added the comment: The changes related to issue 4483 break build on dbm based on "Berkeley DB" so I update mingw patch to restore bulld to previous state. Now I expect test_anydbm, test_bsddb and test_whichdb to succeed as before one week. Added file: http://bugs.python.org/file12272/python-trunk-MINGW.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:30:04 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 21:30:04 +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: <1228685404.27.0.625059944866.issue3871@psf.upfronthosting.co.za> Changes by Roumen Petrov : Removed file: http://bugs.python.org/file12269/python-trunk-MINGW.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:30:17 2008 From: report at bugs.python.org (gumpy) Date: Sun, 07 Dec 2008 21:30:17 +0000 Subject: [issue4583] segfault when mutating memoryview to array.array when array is resized In-Reply-To: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za> Message-ID: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za> New submission from gumpy : This is with r67651 and related to #4569, #4509 and possibly #4580. >>> from array import array >>> a = array('i', range(16)) >>> m = memoryview(a) >>> a.extend(array('i', range(48))) >>> m[:] = array('i', range(64)) Segmentation fault >>> from array import array >>> a = array('b', range(16)) >>> m = memoryview(a) >>> a.extend(array('b', range(48))) >>> m[:] = array('b', range(64)) Segmentation fault ---------- components: Interpreter Core messages: 77260 nosy: gumpy severity: normal status: open title: segfault when mutating memoryview to array.array when array is resized type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:30:30 2008 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Dec 2008 21:30:30 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1228685206.0.0.0371028186692.issue1717@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Sun, Dec 7, 2008 at 13:26, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > About unittest: > > unittest.TestLoader has an attribute "sortTestMethodsUsing", which it > expects to be an old-style comparison. > > Should this attribute be updated (and renamed?) to expect a key function > instead, or left as is? > It will break backwards-compatibility if you change it. Possibly the best solution is to introduce a new attribute that does either key or just lt comparison and make sortTestMethodsUsing be a descriptor that wraps the function as needed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:34:35 2008 From: report at bugs.python.org (gumpy) Date: Sun, 07 Dec 2008 21:34:35 +0000 Subject: [issue4509] bugs in array.array with exports (buffer protocol) In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za> Message-ID: <1228685675.67.0.00527997791681.issue4509@psf.upfronthosting.co.za> gumpy added the comment: I've opened a new memoryview/array segfault issue since #4569 was closed: #4583 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:36:28 2008 From: report at bugs.python.org (Leger) Date: Sun, 07 Dec 2008 21:36:28 +0000 Subject: [issue4581] failed to import module from lib-dynload In-Reply-To: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za> Message-ID: <1228685788.71.0.0515086197577.issue4581@psf.upfronthosting.co.za> Leger added the comment: - "configure --with-pydebug --with-doc-strings --enable-shared --enable-profiling --enable-ipv6 --with-threads --with-tsc --prefix=/usr" - ">>> print(sys.exec_prefix) /usr/lib/python3.0" >>> print(sys.path) ['', '/usr/lib/python3.0', '/home/fred/python', '/usr/lib/python3.0/lib-dynload', '/usr/lib/python3.0/lib/python30.zip', '/usr/lib/python3.0/lib/python3.0', '/usr/lib/python3.0/lib/python3.0/plat-linux2', '/usr/lib/python3.0/lib/python3.0/lib-dynload'] [33634 refs] >>> import time Traceback (most recent call last): File "", line 1, in ImportError: No module named time" I don't understand why I see "/usr/lib/python3.0/lib/python3.0/..." and why the time can't import, it is in "/usr/lib/python3.0/lib-dynload" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:44:07 2008 From: report at bugs.python.org (Michael Yang) Date: Sun, 07 Dec 2008 21:44:07 +0000 Subject: [issue4584] doctest fails to display bytes type In-Reply-To: <1228686247.24.0.760042500601.issue4584@psf.upfronthosting.co.za> Message-ID: <1228686247.24.0.760042500601.issue4584@psf.upfronthosting.co.za> New submission from Michael Yang : doctest.testmod() fails when attempting to echo back a bytes type with ord() > 128. def ok(): """ >>> bytes([255,]) b'\xff' """ pass def notOK(): """ >>> b'\xff' """ pass import doctest doctest.testmod() Traceback (most recent call last): ... UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 141: ordinal not in range(128) ---------- components: Extension Modules messages: 77264 nosy: msyang severity: normal status: open title: doctest fails to display bytes type type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:44:11 2008 From: report at bugs.python.org (Mark Florisson) Date: Sun, 07 Dec 2008 21:44:11 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228686251.23.0.0295185124181.issue4579@psf.upfronthosting.co.za> Mark Florisson added the comment: Perhaps it's linux specific then. I'm on debian lenny (2.6.26-1-amd64). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:46:36 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 07 Dec 2008 21:46:36 +0000 Subject: [issue4581] failed to import module from lib-dynload In-Reply-To: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za> Message-ID: <1228686396.46.0.471049177333.issue4581@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can't reproduce this. Are you sure you didn't configure with --prefix=/usr/lib/python3.0 at some point? That would be about the only way how sys.exec_prefix could get its value? Can you start over with a clean source tree, and try reproducing it again? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:59:52 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Dec 2008 21:59:52 +0000 Subject: [issue4585] Build failure on OS X 10.5.5: make: *** [sharedmods] Error 1 In-Reply-To: <1228687192.04.0.807207077195.issue4585@psf.upfronthosting.co.za> Message-ID: <1228687192.04.0.807207077195.issue4585@psf.upfronthosting.co.za> New submission from Mark Dickinson : There are two recent reports of build failures of Python 3.0 on OS X 10.5.5: see http://mail.python.org/pipermail/python-list/2008-November/514159.html and http://mail.python.org/pipermail/python-3000/2008-December/015404.html It seems likely that these are related. For both reports the build eventually fails with something like: gcc Python.framework/Versions/3.0/Python -o python.exe \ Modules/python.o \ -ldl make: *** [sharedmods] Error 1 I can reproduce this in the py3k branch and release30-maint branch on my Macbook by doing (at a Terminal prompt): export LC_CTYPE="UTF-8" ./configure && make I'll try to find time to look at this; any and all help welcomed! ---------- assignee: marketdickinson messages: 77267 nosy: marketdickinson priority: critical severity: normal status: open title: Build failure on OS X 10.5.5: make: *** [sharedmods] Error 1 type: compile error versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:01:06 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 07 Dec 2008 22:01:06 +0000 Subject: [issue4584] doctest fails to display bytes type In-Reply-To: <1228686247.24.0.760042500601.issue4584@psf.upfronthosting.co.za> Message-ID: <1228687266.9.0.669949955204.issue4584@psf.upfronthosting.co.za> Georg Brandl added the comment: You've included a chr(255) character in your docstring. You need to escape the backslash in order to include the bytes representation like it will be generated. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:10:28 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 07 Dec 2008 22:10:28 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228684073.44.0.102970903142.issue4483@psf.upfronthosting.co.za> Message-ID: <18748.18894.646908.763084@montanaro-dyndns-org.local> Skip Montanaro added the comment: Roumen> I'm not sure that recent commits in trunk are correct. Roumen> Please confirm that build of dbm module with "Berkeley DB" is Roumen> deprecated. Can you explain how you think they are incorrect? The code to decide how to build the dbm module looks like this: if we have ndbm.h: build dbm using ndbm else if we have a gdbm library: if we have gdbm/ndbm.h: build dbm using gdbm else if we have gdbm-ndbm.h: build dbm using gdbm else if we found Berkeley includes: build dbm using Berkeley db. This overall structure agrees with that in the Python 2.4 and 2.5 setup.py. The only thing that changed (in theory) was that there's an extra check for gdbm-ndbm.h after we've already decided to build dbm with gdbm. The preference is still ndbm before gdbm before BerkDB. That's not to say it's correct, but nothing's changed as far as I can tell. Maybe it should look more like this: dbmext = None if we have ndbm.h: ... dbmext = Extension(...) if dbmext is None and we have a gdbm library: if we have gdbm/ndbm.h: ... dbmext = Extension(...) else if we have gdbm-ndbm.h: ... dbmext = Extension(...) if dbmext is None and we found Berkeley includes: ... dbmext = Extension(...) if dbmext is not None: exts.append(dbmext) That still leaves the order ndbm before gdbm before BerkDB. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:16:56 2008 From: report at bugs.python.org (Leger) Date: Sun, 07 Dec 2008 22:16:56 +0000 Subject: [issue4581] failed to import module from lib-dynload In-Reply-To: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za> Message-ID: <1228688216.73.0.225298063885.issue4581@psf.upfronthosting.co.za> Leger added the comment: Ok Martin, I delete all source and /usr/lib/python3.0, restart from the tarball. I apply the patch dbm.diff (issue4581) and after : "configure --with-pydebug --with-doc-strings --enable-shared --enable-profiling --enable-ipv6 --with-threads --with-tsc --prefix=/usr > ../configure.log 2>&1 make > ../make.log 2>&1 make altinstall > ../altinstall.log 2>&1" Launch "python3.0" and test import : >>> import math, cmath, bz2, crypt, readline [34363 refs] SUCCESSFUL ! So "make clean" can't always sufficient, I learn than in some case need to restart from the tarball is a necessary test. Many thinks for this lesson. You can close this issue. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:32:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 07 Dec 2008 22:32:39 +0000 Subject: [issue4578] compiler: -3 warnings In-Reply-To: <1228671347.68.0.444266504353.issue4578@psf.upfronthosting.co.za> Message-ID: <1228689159.2.0.594126499255.issue4578@psf.upfronthosting.co.za> Georg Brandl added the comment: Since the compiler package is removed in Python 3, I think it's okay for it to raise py3k warnings -- in fact, it should raise a quite prominent one when first imported that it's going to be removed. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:42:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 07 Dec 2008 22:42:20 +0000 Subject: [issue4457] __import__ documentation obsolete In-Reply-To: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za> Message-ID: <1228689740.83.0.992076701171.issue4457@psf.upfronthosting.co.za> Georg Brandl added the comment: Changed patch to document sys.modules trick and applied in r67654. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:42:22 2008 From: report at bugs.python.org (blake madden) Date: Sun, 07 Dec 2008 22:42:22 +0000 Subject: [issue4586] "Extending Embedded Python" documention uses removed Py_InitModule function In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> Message-ID: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> New submission from blake madden : On the page: http://docs.python.org/3.0/extending/embedding.html#extending-embedded-python Note that the function "Py_InitModule" is used. From what I can tell, this function no longer exists and regrettably I can't figure out how to get "PyModule_Create" to work in its place. ---------- assignee: georg.brandl components: Documentation messages: 77273 nosy: blakemadden, georg.brandl severity: normal status: open title: "Extending Embedded Python" documention uses removed Py_InitModule function versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:46:05 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 07 Dec 2008 22:46:05 +0000 Subject: [issue4586] "Extending Embedded Python" documention uses removed Py_InitModule function In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> Message-ID: <1228689965.44.0.712376029826.issue4586@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be fixed in r67655. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:52:09 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 07 Dec 2008 22:52:09 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za> Message-ID: <1228690329.12.0.991200522446.issue4483@psf.upfronthosting.co.za> Roumen Petrov added the comment: The old if statement was "flat": if find_file("ndbm.h", inc_dirs, []) is not None: elif (self.compiler.find_library_file(lib_dirs, 'gdbm') and find_file("gdbm/ndbm.h", inc_dirs, []) is not None): elif db_incs is not None: else: miss If the second case fail, try third and if succeed build dbm with "berkeley db". The new if statement contain nested if: Now the second case is only "self.compiler.find_library_file(lib_dirs, 'gdbm'):" and if succeed (my case) => Failed to find the necessary bits to build these modules: ... dbm ... Note the build system lack headers "gdbm/ndbm.h", "gdbm-ndbm.h". To restore previous I add copy of code from third case as new case in nested if: =============== 'dbm', ['dbmmodule.c'], define_macros=[('HAVE_GDBM_DASH_NDBM_H',None)], libraries = gdbm_libs ) ) + elif db_incs is not None: + exts.append( Extension('dbm', ['dbmmodule.c'], + library_dirs=dblib_dir, + runtime_library_dirs=dblib_dir, + include_dirs=db_incs, + define_macros=[('HAVE_BERKDB_H',None), + ('DB_DBM_HSEARCH',None)], + libraries=dblibs)) else: missing.append('dbm') elif db_incs is not None: =============== Note that above is not proposed patch as I don't like nested ifs and code duplicate. Is possible the checks to be in a new separate function ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:19:57 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Sun, 07 Dec 2008 23:19:57 +0000 Subject: [issue4578] compiler: -3 warnings In-Reply-To: <1228671347.68.0.444266504353.issue4578@psf.upfronthosting.co.za> Message-ID: <1228691997.58.0.653769281244.issue4578@psf.upfronthosting.co.za> Sebastian Rittau added the comment: I'd like to see this fixed, just to decrease the amount of warning spam I get when testing my own packages. It seems that one of my dependecies that I have no control over is pulling this in. Adding a warning when this module is important seems like a good idea, though. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:45:58 2008 From: report at bugs.python.org (Calvin Spealman) Date: Sun, 07 Dec 2008 23:45:58 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228693558.39.0.0867185868448.issue4579@psf.upfronthosting.co.za> Changes by Calvin Spealman : ---------- nosy: +ironfroggy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:48:52 2008 From: report at bugs.python.org (Calvin Spealman) Date: Sun, 07 Dec 2008 23:48:52 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228693732.21.0.155455940859.issue4579@psf.upfronthosting.co.za> Calvin Spealman added the comment: Confirmed this behavior on my ubuntu installations but it fails properly on Windows. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 01:03:56 2008 From: report at bugs.python.org (Calvin Spealman) Date: Mon, 08 Dec 2008 00:03:56 +0000 Subject: [issue4573] zsh-style subpattern matching for fnmatch/glob In-Reply-To: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za> Message-ID: <1228694636.75.0.494692968738.issue4573@psf.upfronthosting.co.za> Calvin Spealman added the comment: This should be applicable to 2.7, at least, as well. Here is a backport of the patch against trunk. ---------- nosy: +ironfroggy Added file: http://bugs.python.org/file12273/zsh-fnmatch-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 01:04:08 2008 From: report at bugs.python.org (Calvin Spealman) Date: Mon, 08 Dec 2008 00:04:08 +0000 Subject: [issue4573] zsh-style subpattern matching for fnmatch/glob In-Reply-To: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za> Message-ID: <1228694648.34.0.986582523803.issue4573@psf.upfronthosting.co.za> Changes by Calvin Spealman : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 02:10:53 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 08 Dec 2008 01:10:53 +0000 Subject: [issue4199] add shorthand global and nonlocal statements In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za> Message-ID: <1228698653.1.0.517767802923.issue4199@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- priority: high -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 02:16:36 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Dec 2008 01:16:36 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <1228690329.12.0.991200522446.issue4483@psf.upfronthosting.co.za> Message-ID: <18748.30060.11371.927803@montanaro-dyndns-org.local> Skip Montanaro added the comment: Roumen> The old if statement was "flat": ... Okay, I understand now. Roumen> The new if statement contain nested if: Roumen> Now the second case is only "self.compiler.find_library_file(lib_dirs, Roumen> 'gdbm'):" and if succeed (my case) => Roumen> Failed to find the necessary bits to build these modules: Roumen> ... dbm ... Roumen> Note the build system lack headers "gdbm/ndbm.h", "gdbm-ndbm.h". In my mind that simply means we haven't accounted for how your system has organized its header files. It has a libgdbm so it probably has some sort of gdbm header file unless you have failed to install some package. I'm beginning to think this area needs more work. Let's leave this ticket closed. I'll open a new one so we can figure out the best way to tackle this. In the meantime can you figure out why your system has a gdbm library but apparently no gdbm headers (or different ones than we are currently testing for)? Thx, Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 02:22:51 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Dec 2008 01:22:51 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <18748.30438.749825.192737@montanaro-dyndns-org.local> New submission from Skip Montanaro : Fixing issue4483 resulted in adding an extra header file check for gdbm-based header files when the gdbm library was found. This caused problems for Roumen Petrov. In considering the problems he encountered I decided we probably need to provide users some more flexibility when deciding which libraries and header files to use when building the dbm module (or _dbm on 3.0). For example, the current hard-coded perform checks in this order: ndbm, gdbm, BerkDB. What if the system has hdbm installed but the builder wants to use the BerkDB compatibility API? This ticket is to track the discussion and come up with a suitable system. ---------- messages: 77280 nosy: skip.montanaro severity: normal status: open title: Need to rework the dbm lib/include selection process _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 02:23:38 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Dec 2008 01:23:38 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <1228699418.73.0.551502748141.issue4587@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- components: +Build nosy: +rpetrov priority: -> normal type: -> behavior versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 02:48:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 08 Dec 2008 01:48:44 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228700924.88.0.524564332333.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: The latest patch removes PyUnicode_Compare as well as lots of __cmp__ functions under Lib/. It also renames and redefines PyUnicode_CompareWithASCIIString(). The simpler PyUnicode_EqualToASCIIString() function is easier to use, too. ---------- stage: -> needs patch Added file: http://bugs.python.org/file12274/remove_cmp4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 02:50:15 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Dec 2008 01:50:15 +0000 Subject: [issue4483] Error to build _dbm module during make In-Reply-To: <18748.30060.11371.927803@montanaro-dyndns-org.local> Message-ID: <18748.32082.191286.997993@montanaro-dyndns-org.local> Skip Montanaro added the comment: Skip> I'm beginning to think this area needs more work. Let's leave Skip> this ticket closed. I'll open a new one so we can figure out the Skip> best way to tackle this. http://bugs.python.org/issue4587 Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 03:05:23 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Dec 2008 02:05:23 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <1228701923.76.0.866263922201.issue4587@psf.upfronthosting.co.za> Skip Montanaro added the comment: Roumen, can you take a look at (and try) the attached patch? It uses an environment variable, PYDBMLIBORDER to define the order of libraries to check for dbm build suitability. If not specified it defaults to "ndbm:gdbm:bdb". ---------- keywords: +patch Added file: http://bugs.python.org/file12275/setup.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 03:42:26 2008 From: report at bugs.python.org (Gregg Lind) Date: Mon, 08 Dec 2008 02:42:26 +0000 Subject: [issue4568] Improved optparse "varargs" callback example In-Reply-To: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za> Message-ID: <1228704146.83.0.801552729916.issue4568@psf.upfronthosting.co.za> Changes by Gregg Lind : ---------- versions: +Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 04:00:24 2008 From: report at bugs.python.org (Gregg Lind) Date: Mon, 08 Dec 2008 03:00:24 +0000 Subject: [issue4320] optparse: "1 2 3" should be seen as one string In-Reply-To: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za> Message-ID: <1228705224.64.0.303514403348.issue4320@psf.upfronthosting.co.za> Gregg Lind added the comment: Can you show an example of this not working? Works fine for me in 2.4/2.5/2.6. ---------- nosy: +gregg.lind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 04:07:13 2008 From: report at bugs.python.org (lion.guo) Date: Mon, 08 Dec 2008 03:07:13 +0000 Subject: [issue4406] In Lib\tkinter\filedialog.py, class Directory define loss a"_" In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za> Message-ID: <1228705633.11.0.620282681677.issue4406@psf.upfronthosting.co.za> lion.guo added the comment: Why didn't include this patch in python 3.0 ???? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 04:29:30 2008 From: report at bugs.python.org (jeff deifik) Date: Mon, 08 Dec 2008 03:29:30 +0000 Subject: [issue4588] Need a way to make my own bytes In-Reply-To: <1228706970.47.0.163581858877.issue4588@psf.upfronthosting.co.za> Message-ID: <1228706970.47.0.163581858877.issue4588@psf.upfronthosting.co.za> New submission from jeff deifik : I want to make my own data of types bytes in order to write it out. For example, I want to write out the bytes 0..9 #!/usr/bin/env python3.0 foo = b'' for i in range (0,10): foo += i #sys.stdout.buffer.write(foo) Here is the error: Traceback (most recent call last): File "./x.py", line 4, in foo += i TypeError: can't concat bytes to int I cannot find any function to convert the int i into something that I can append to foo. I tried chr, which produced a string typeerror. byte() was not defined. There must be a way to convert an integral value to a bytes type. ---------- components: Interpreter Core messages: 77286 nosy: lopgok severity: normal status: open title: Need a way to make my own bytes type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 04:58:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 03:58:12 +0000 Subject: [issue4581] failed to import module from lib-dynload In-Reply-To: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za> Message-ID: <1228708692.5.0.930266124868.issue4581@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 05:14:39 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 08 Dec 2008 04:14:39 +0000 Subject: [issue4588] Need a way to make my own bytes In-Reply-To: <1228706970.47.0.163581858877.issue4588@psf.upfronthosting.co.za> Message-ID: <1228709679.09.0.200532213119.issue4588@psf.upfronthosting.co.za> Benjamin Peterson added the comment: bytes([some_number]) should do the trick. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 05:45:26 2008 From: report at bugs.python.org (jeff deifik) Date: Mon, 08 Dec 2008 04:45:26 +0000 Subject: [issue4588] Need a way to make my own bytes In-Reply-To: <1228706970.47.0.163581858877.issue4588@psf.upfronthosting.co.za> Message-ID: <1228711526.13.0.559912660442.issue4588@psf.upfronthosting.co.za> jeff deifik added the comment: Doesn't work. #!/usr/bin/env python3.0 import sys foo = b'' for i in range (0,10): foo += bytes(i) sys.stdout.buffer.write(foo) produces a binary file of 45 bytes. Here is a hex dump (the '.' represent unprintable characters): +000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +032 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. that is 45 bytes of 0. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 06:08:19 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 05:08:19 +0000 Subject: [issue4588] Need a way to make my own bytes In-Reply-To: <1228706970.47.0.163581858877.issue4588@psf.upfronthosting.co.za> Message-ID: <1228712899.51.0.328650262796.issue4588@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please don't use the bug tracker to obtain help, but only to report bugs. Use python-list at python.org to get help. In this specific case, also read Benjamin's answer more carefully. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 07:21:11 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 08 Dec 2008 06:21:11 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin : When a context manager's __exit__() method returns an object whose conversion to bool raises an exception, 'with' loses that exception. For example: >>> class CM(object): ... def __init__(self, exit_result): ... self.exit_result = exit_result ... def __enter__(self): ... return 3 ... def __exit__(self, a, b, c): ... return self.exit_result() ... >>> class TrueAsBool(object): ... def __nonzero__(self): return True ... >>> class FalseAsBool(object): ... def __nonzero__(self): return False ... >>> class FailAsBool(object): ... def __nonzero__(self): ... raise RuntimeError("Should see this but won't") ... >>> with CM(TrueAsBool): ... raise AssertionError("Should NOT see this") ... >>> with CM(FalseAsBool): ... raise AssertionError("Should see this") ... Traceback (most recent call last): File "", line 2, in AssertionError: Should see this >>> with CM(FailAsBool): ... raise AssertionError("Should see RuntimeException (oops)") ... >>> The problem is that WITH_CLEANUP only checks if PyObject_IsTrue(x) returns non-zero, but that function returns <0 when the bool conversion raises an exception. ---------- assignee: jyasskin components: Interpreter Core messages: 77290 nosy: jyasskin severity: normal stage: needs patch status: open title: 'with' loses ->bool exceptions type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 08:30:58 2008 From: report at bugs.python.org (Matthias Klose) Date: Mon, 08 Dec 2008 07:30:58 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228721458.4.0.073485536427.issue4552@psf.upfronthosting.co.za> Matthias Klose added the comment: > In my opinion the tar balls should contain all necessary bits and pieces > to build the docs yourself. It makes no sense to include the Doc/ folder > w/o any means to use them. + 1 > Let's include sphinxext and document the required versions of sphinx, > docutils and jinja. - 1, we didn't include latex in 2.5 as well. sphinxext isn't included in sphinx, so it should be included in the release tarball. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 09:20:31 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 08 Dec 2008 08:20:31 +0000 Subject: [issue4523] logging module __init__ uses has_key In-Reply-To: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za> Message-ID: <1228724431.71.0.446807075509.issue4523@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> georg.brandl nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 10:44:44 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 08 Dec 2008 09:44:44 +0000 Subject: [issue4555] Smelly exports In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> Message-ID: <1228729484.28.0.431986685156.issue4555@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: For Python 2.x you cannot change the "main" function name of C extensions, since this is used by the Python import mechanism. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 10:49:46 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 08 Dec 2008 09:49:46 +0000 Subject: [issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so In-Reply-To: <1189921072.53.0.557521657427.issue1167@psf.upfronthosting.co.za> Message-ID: <1228729786.79.0.142717501195.issue1167@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Fixed in r67614. (issue4483) ---------- nosy: +ocean-city resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 11:19:57 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 08 Dec 2008 10:19:57 +0000 Subject: [issue4579] .read() and .readline() differ in failing In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za> Message-ID: <1228731597.59.0.0535729970205.issue4579@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Python 2 is very platform-dependent: fdopen simply call the C function fdopen() and returns a FILE*. Since the sample code is a mistake (read on a file open in write mode), how and when the error shows up really depends on the platform's implementation of the FILE* object. On the other hand Python 3 re-implemented all this, no FILE is used. The io.UnsupportedOperation("BufferedWriter.read() not supported") is much better IMO. And note that io.UnsupportedOperation is a IOError as well. However the AttributeError is inconsistent. The attached patch turns it into a UnsupportedOperation as above. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc priority: -> normal versions: -Python 2.4, Python 2.5 Added file: http://bugs.python.org/file12276/bad_readline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 11:36:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 08 Dec 2008 10:36:55 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228732615.21.0.630360711939.issue4552@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't want to *include* sphinx, jinja and docutils but *document* which versions of sphinx, jinja and docutils are required to build the docs. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 12:09:17 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 11:09:17 +0000 Subject: [issue4590] 2to3 strips trailing L for long iterals in two fixers In-Reply-To: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za> Message-ID: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za> New submission from Armin Ronacher : I noticed that fix_long and fix_numliterals both strip trailing Ls from numbers. That's redudant, one of them should be enough. I attached a patch that removes the literal changing from the fix_long fixer. Because I'm not sure if that may be the correct fixer to modify I didn't commit it but created an issue for review. ---------- assignee: benjamin.peterson components: 2to3 (2.x to 3.0 conversion tool) files: remove_redundant.diff keywords: needs review, patch messages: 77296 nosy: aronacher, benjamin.peterson priority: normal severity: normal stage: patch review status: open title: 2to3 strips trailing L for long iterals in two fixers type: behavior versions: 3rd party Added file: http://bugs.python.org/file12277/remove_redundant.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 12:23:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 08 Dec 2008 11:23:50 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228735430.44.0.745263555565.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: Update patch to include fix for unittest.py and test_unittest.py. Added file: http://bugs.python.org/file12278/remove_cmp5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 12:39:51 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 11:39:51 +0000 Subject: [issue3563] fix_idioms.py generates bad code In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za> Message-ID: <1228736391.85.0.256717771972.issue3563@psf.upfronthosting.co.za> Armin Ronacher added the comment: I would drop the prefix in that case or attach it to the sorted() call. So from this code: x = foo() # perform sorting x.sort() to # perform sorting x = sorted(foo()) Makes more sense than sticking it after the sorted() call like it happens currently. This should also fix the problem with outdented statements such as except/finally. ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 12:55:59 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 11:55:59 +0000 Subject: [issue2356] fixer for sys.exitfunc -> atexit In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za> Message-ID: <1228737359.1.0.709303184477.issue2356@psf.upfronthosting.co.za> Armin Ronacher added the comment: Since yesterday there is a handy little helper that adds imports to files which is already used for the reduce() / intern() fixers. This makes this fix a lot easier. I attached a version that does that. However the import adder is not yet as sophisticated as the one in the previous patch, but the utility method could be improved to better adapt to existing styleguides. ---------- nosy: +aronacher Added file: http://bugs.python.org/file12279/fix_exitfunc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 13:18:48 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 12:18:48 +0000 Subject: [issue2734] 2to3 converts long(itude) argument to int In-Reply-To: <1209669660.53.0.857681626906.issue2734@psf.upfronthosting.co.za> Message-ID: <1228738728.24.0.0745761286579.issue2734@psf.upfronthosting.co.za> Armin Ronacher added the comment: This could probably be fixed by adding a `is_builtin` helper function to the fixer_util module that checks if the name is not overriden in the module. I would use something like a weak dictionary for the `find_binding` function because that could turn out to be quite expensive. Besides long this is probably also useful for `reduce` and some others. ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 13:22:11 2008 From: report at bugs.python.org (Sjoerd Mullender) Date: Mon, 08 Dec 2008 12:22:11 +0000 Subject: [issue4591] uid/gid problem in os.chown In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> Message-ID: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> New submission from Sjoerd Mullender : On Fedora 8 and 10 using Python 2.5.1 and 2.5.2 (64 bit): $ grep nfsnobody /etc/passwd nfsnobody:x:4294967294:4294967294:Anonymous NFS User:/var/lib/nfs:/sbin/nologin So the UID of nfsnobody is 4294967294 (-2 if viewed as signed 32-bit int). >>> import pwd, os >>> print pwd.getpwnam('nfsnobody').pw_uid 4294967294 >>> os.chown('some file', pwd.getpwnam('nfsnobody').pw_uid, pwd.getpwnam('nfsnobody').pw_gid) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum The reason for this error is that os.chown uses the "i" format to convert the second and third arguments. But the valued do not fit in a 32-bit signed integer. uid_t and gid_t are defined as unsigned quantities on this system. The bug does not occur on 32 bit Fedora since there the uid and gid of nfsnobody are 65534. ---------- components: Library (Lib) messages: 77301 nosy: sjoerd severity: normal status: open title: uid/gid problem in os.chown type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 14:18:12 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 08 Dec 2008 13:18:12 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228742292.74.0.13615830793.issue4589@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Good catch. Here is a patch, with test. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc priority: -> normal stage: needs patch -> patch review Added file: http://bugs.python.org/file12280/with_badbool.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 14:21:26 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 08 Dec 2008 13:21:26 +0000 Subject: [issue4577] distutils: -3 warnings (apply) In-Reply-To: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za> Message-ID: <1228742486.04.0.707381413879.issue4577@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Patch is good. ---------- assignee: -> amaury.forgeotdarc nosy: +amaury.forgeotdarc stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 14:35:35 2008 From: report at bugs.python.org (blake madden) Date: Mon, 08 Dec 2008 13:35:35 +0000 Subject: [issue4586] "Extending Embedded Python" documention uses removed Py_InitModule function In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> Message-ID: <1228743335.41.0.811590444319.issue4586@psf.upfronthosting.co.za> blake madden added the comment: I am afraid that the webpage that I mentioned still uses "Py_InitModule", I just checked. How do I get embedding to work? Thanks. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 14:40:50 2008 From: report at bugs.python.org (blake madden) Date: Mon, 08 Dec 2008 13:40:50 +0000 Subject: [issue4586] "Extending Embedded Python" documention uses removed Py_InitModule function In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> Message-ID: <1228743650.25.0.773742819756.issue4586@psf.upfronthosting.co.za> blake madden added the comment: I took a look at the rst file in your comments and I tried that example (which uses PyModule_Create), but I am sorry to say that it doesn't work. It says "no module named emb". Are we sure that PyModule_Create is all that needs to be called? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 14:56:37 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 08 Dec 2008 13:56:37 +0000 Subject: [issue4591] uid/gid problem in os.chown In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> Message-ID: <1228744597.08.0.674440620691.issue4591@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This was already corrected by r61540, and will be released with 2.5.3 and 2.6.2. BUT -- fchown() was not modified. patch is similar to r61540, but I don't know how to test: Index: posixmodule.c =================================================================== --- posixmodule.c (revision 67068) +++ posixmodule.c (working copy) @@ -1902,9 +1902,10 @@ static PyObject * posix_fchown(PyObject *self, PyObject *args) { - int fd, uid, gid; + int fd; + long uid, gid; int res; - if (!PyArg_ParseTuple(args, "iii:chown", &fd, &uid, &gid)) + if (!PyArg_ParseTuple(args, "ill:fchown", &fd, &uid, &gid)) return NULL; Py_BEGIN_ALLOW_THREADS res = fchown(fd, (uid_t) uid, (gid_t) gid); ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc priority: -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:00:51 2008 From: report at bugs.python.org (blake madden) Date: Mon, 08 Dec 2008 15:00:51 +0000 Subject: [issue4592] PyModule_Create doesn't work (or example is missing something) In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> New submission from blake madden : Following an example of how to extend and embed that I found in patch file r67655 (the website is out of date [issue4586]), PyModule_Create appears to not work (or example is not complete). When I run r67655 (attached also) I get an error saying that "emb" is not a module. ---------- components: Extension Modules files: python.cpp messages: 77307 nosy: blakemadden severity: normal status: open title: PyModule_Create doesn't work (or example is missing something) versions: Python 3.0 Added file: http://bugs.python.org/file12281/python.cpp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:04:13 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 15:04:13 +0000 Subject: [issue2454] sha and md5 fixer In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za> Message-ID: <1228748653.68.0.442044978013.issue2454@psf.upfronthosting.co.za> Changes by Armin Ronacher : ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:04:20 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 15:04:20 +0000 Subject: [issue2899] Fixers find, rfind, etc in 'string' module In-Reply-To: <1211027417.56.0.456898655973.issue2899@psf.upfronthosting.co.za> Message-ID: <1228748660.88.0.640310818072.issue2899@psf.upfronthosting.co.za> Changes by Armin Ronacher : ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:04:48 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 15:04:48 +0000 Subject: [issue2805] 2to3 doesn't correct divisions In-Reply-To: <1210366311.62.0.240931801365.issue2805@psf.upfronthosting.co.za> Message-ID: <1228748688.38.0.333259487347.issue2805@psf.upfronthosting.co.za> Changes by Armin Ronacher : ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:31:29 2008 From: report at bugs.python.org (nelis) Date: Mon, 08 Dec 2008 15:31:29 +0000 Subject: [issue4585] Build failure on OS X 10.5.5: make: *** [sharedmods] Error 1 In-Reply-To: <1228687192.04.0.807207077195.issue4585@psf.upfronthosting.co.za> Message-ID: <1228750289.87.0.00472763812187.issue4585@psf.upfronthosting.co.za> nelis added the comment: You asked how my locale looked, I've got: 10-92-86-47:Python-3.0 nelis$ locale LANG= LC_COLLATE="C" LC_CTYPE="UTF-8" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL= So I the LC_CTYPE is indeed UTF-8. I can also confirm that I can make if I first run `export LC_CTYPE="nl_BE.UTF-8"' (the setting a friend of mine has). I still get the following error, but I think it is unrelated and I can ignore it and go on: Failed to find the necessary bits to build these modules: _gdbm ossaudiodev readline spwd Afterwards I have been playing around with internationalization a bit, trying to change the LC_CTYPE. Changing it to "United States (Computer)", or to "Belgium (Dutch)" changed the other locale settings to nl_be.UTF-8 but not the LC_CTYPE. The problem might be in OSX, but it is still strange that this makes building in python impossible. ---------- nosy: +nelis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:33:57 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 08 Dec 2008 15:33:57 +0000 Subject: [issue4336] Fix performance issues in xmlrpclib In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> Message-ID: <1228750437.07.0.636315662405.issue4336@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Please consider applying this patch. It moves the logic handling of non-string message_body inside of endheaders(), allowind clients of HTTPConnection to substitute endheader();send(data) with endheaders(data) without fear. Added file: http://bugs.python.org/file12282/httplib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:34:59 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 08 Dec 2008 15:34:59 +0000 Subject: [issue4336] Fix performance issues in xmlrpclib In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> Message-ID: <1228750499.97.0.0182797796132.issue4336@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: In light of my previous patch, here is a an improvement to urllib.py and logging that uses endheaders(body) Added file: http://bugs.python.org/file12283/htmllibclients.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:35:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 08 Dec 2008 15:35:46 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228750546.81.0.437371936913.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: I've created a new branch to work on the issue: svn+ssh://pythondev at svn.python.org/python/branches/py3k-issue1717. It's easier to work on a branch than exchanging monster patches. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:45:20 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 08 Dec 2008 15:45:20 +0000 Subject: [issue4593] Documentation for multiprocessing - Pool.apply() In-Reply-To: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za> Message-ID: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za> New submission from David M. Beazley : The documentation for the apply() and apply_async() methods of a Pool object might emphasize that these operations execute func(*args,**kwargs) in only one of the pool workers and that func() is not being executed in parallel on all workers. On first reading, I actually thought it might be the latter (and had to do some experimentation to figure out what was actually happening). ---------- assignee: georg.brandl components: Documentation messages: 77312 nosy: beazley, georg.brandl severity: normal status: open title: Documentation for multiprocessing - Pool.apply() versions: Python 2.6, Python 2.7, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:50:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 08 Dec 2008 15:50:59 +0000 Subject: [issue4593] Documentation for multiprocessing - Pool.apply() In-Reply-To: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za> Message-ID: <1228751459.75.0.0345376017908.issue4593@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: georg.brandl -> jnoller keywords: +easy nosy: +jnoller priority: -> normal stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:53:17 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 08 Dec 2008 15:53:17 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228751597.98.0.78663209603.issue1717@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Please put the PyUnicode_Compare() API back in there. Removing __cmp__ really doesn't have anything to do with removing often used helper functions for comparing certain object types and only cripples the C API in a needless way. Thanks. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:57:17 2008 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 08 Dec 2008 15:57:17 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <1228751837.04.0.63004464427.issue4587@psf.upfronthosting.co.za> Roumen Petrov added the comment: About my environment : - one is linux : a) gdbm library, with header gdbm.h, without *ndbm.h b) "Berkeley DB" many versions but the last is 4.4 I think - other is cross and native(msys) mingw32 environment only "Berkeley DB" 4.7 I will check later the patch but at first look is expected to fail. Lets see http://svn.python.org/view/python/trunk/Modules/dbmmodule.c?rev=67614&view=auto . This module don't include gdbm.h header. I expect linux build to fail with error "No ndbm.h available!" I could test patch later when I get access to build environment. Did you like I to test what is result (linux build) when header gdbm.h is included in module ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:07:31 2008 From: report at bugs.python.org (John Stracke) Date: Mon, 08 Dec 2008 16:07:31 +0000 Subject: [issue4594] Can't compile with -O3, on ARM, with gcc 3.4.4 In-Reply-To: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za> Message-ID: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za> New submission from John Stracke : I downloaded the source to Python 3.0 onto my Nokia N810, an ARM-based Linux machine. The native gcc is 3.4.4 (upgrading might be possible, but would certainly be a pain). I was able to build only by switching from -O3 to -O2; -O3 caused a compiler crash. Now, this isn't really Python's fault; gcc really shouldn't be crashing. However, it'd be nice if configure had a way to specify the optimization level--I had to go in and edit the generated Makefile by hand. Better yet would be if configure could recognize the platform and set the -O level accordingly. ---------- components: Build messages: 77315 nosy: metageek severity: normal status: open title: Can't compile with -O3, on ARM, with gcc 3.4.4 versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:11:36 2008 From: report at bugs.python.org (Jesse Noller) Date: Mon, 08 Dec 2008 16:11:36 +0000 Subject: [issue4593] Documentation for multiprocessing - Pool.apply() In-Reply-To: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za> Message-ID: <1228752696.31.0.558089357344.issue4593@psf.upfronthosting.co.za> Jesse Noller added the comment: Ah, I see what you're talking about David. Good catch. It wouldn't make sense to run the apply() in all of the workers, as apply() is a single function(...) call. map() however is done in parallel amongst all workers. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:13:35 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 08 Dec 2008 16:13:35 +0000 Subject: [issue4585] Build failure on OS X 10.5.5: make: *** [sharedmods] Error 1 In-Reply-To: <1228687192.04.0.807207077195.issue4585@psf.upfronthosting.co.za> Message-ID: <1228752815.76.0.575885661436.issue4585@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the information, nelis! This appears to be a duplicate of issue 2173. Further analysis should go there. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:13:53 2008 From: report at bugs.python.org (Jesse Noller) Date: Mon, 08 Dec 2008 16:13:53 +0000 Subject: [issue3206] Multiprocessing Array and sharedctypes.Array error in docs/implementation In-Reply-To: <1214473998.34.0.913565828871.issue3206@psf.upfronthosting.co.za> Message-ID: <1228752833.47.0.464369880238.issue3206@psf.upfronthosting.co.za> Changes by Jesse Noller : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:13:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 08 Dec 2008 16:13:58 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1228752838.82.0.107234121618.issue2173@psf.upfronthosting.co.za> Mark Dickinson added the comment: See issue 4585, which appears to be the same problem. ---------- nosy: +marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:14:00 2008 From: report at bugs.python.org (Jesse Noller) Date: Mon, 08 Dec 2008 16:14:00 +0000 Subject: [issue3206] Multiprocessing Array and sharedctypes.Array error in docs/implementation In-Reply-To: <1214473998.34.0.913565828871.issue3206@psf.upfronthosting.co.za> Message-ID: <1228752840.62.0.686108293215.issue3206@psf.upfronthosting.co.za> Jesse Noller added the comment: Dupe, issue4449 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:19:22 2008 From: report at bugs.python.org (David W. Lambert) Date: Mon, 08 Dec 2008 16:19:22 +0000 Subject: [issue2899] Fixers find, rfind, etc in 'string' module In-Reply-To: <1211027417.56.0.456898655973.issue2899@psf.upfronthosting.co.za> Message-ID: <1228753162.14.0.965599525422.issue2899@psf.upfronthosting.co.za> David W. Lambert added the comment: I expect the answer will be that 2to3 cannot know what sort of object "string" names. Bell's theorem, or some such, as I understand it, tells us that you must execute the algorithm to find out what it does, there isn't a short cut. It does seem like 2to3 could assume that you write code with honorable intention, grace, and style and thereby offer a suggestive note. The string module is not an isolated case for such notices. I made a similar request to yours for "file" which is gone in version 3. Unfortunately, code as follows is probably frequent, so we aren't likely to get support for this feature. Maybe here is an opportunity for venture capital! def f(list): ''' argument should be a list. "list" in this scope no longer names __builtins__.list ''' ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:23:54 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 08 Dec 2008 16:23:54 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1228753434.87.0.205349108689.issue2173@psf.upfronthosting.co.za> Mark Dickinson added the comment: I think I've traced the 'no output' problem back to the device_encoding function in Modules/posixmodule.c. The problem occurs when this function is called to try to get the encoding for stdout. On my machine, if I do: LC_CTYPE="UTF-8" ./python.exe then the nl_langinfo call in device_encoding returns an empty string. If I do LC_CTYPE="bogus" ./python.exe then it returns "US-ASCII" and if I do LC_CTYPE="en_US.UTF-8" ./python.exe then it returns "UTF-8". In the first case (where the encoding is set to ""), any subsequent attempts to send anything to stdout result in a LookupError with the message "unknown encoding". But of course, since this exception message is itself sent to stdout (or possibly stderr?) the same problem occurs again and we just don't see any output. I don't yet know why this causes the module build to fail, or why exit() doesn't work. I think we should try to get this fixed before 3.0.1. Any help would be welcomed. ---------- priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:24:02 2008 From: report at bugs.python.org (blake madden) Date: Mon, 08 Dec 2008 16:24:02 +0000 Subject: [issue4592] PyModule_Create doesn't work (or example is missing something) In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228753442.38.0.155056278025.issue4592@psf.upfronthosting.co.za> blake madden added the comment: It seems that a call to "PyDict_SetItemString" is what is missing from r67655: PyObject* m = PyModule_Create(&EmbModule); PyDict_SetItemString(PyImport_GetModuleDict(), EmbModule.m_name, m); I am just guessing here though, don't know if this is correct way to do things. ---------- assignee: -> georg.brandl components: +Documentation -Extension Modules nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:24:42 2008 From: report at bugs.python.org (blake madden) Date: Mon, 08 Dec 2008 16:24:42 +0000 Subject: [issue4592] Example patch is missing something In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228753482.77.0.422763168873.issue4592@psf.upfronthosting.co.za> Changes by blake madden : ---------- title: PyModule_Create doesn't work (or example is missing something) -> Example patch is missing something _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:26:39 2008 From: report at bugs.python.org (blake madden) Date: Mon, 08 Dec 2008 16:26:39 +0000 Subject: [issue4595] new types example is out of date In-Reply-To: <1228753599.51.0.736503605174.issue4595@psf.upfronthosting.co.za> Message-ID: <1228753599.51.0.736503605174.issue4595@psf.upfronthosting.co.za> New submission from blake madden : http://docs.python.org/3.0/extending/newtypes.html This example is using Py_InitModule3, is this function removed in Python 3? ---------- assignee: georg.brandl components: Documentation messages: 77323 nosy: blakemadden, georg.brandl severity: normal status: open title: new types example is out of date versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:40:19 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 08 Dec 2008 16:40:19 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228754419.06.0.475982879058.issue4589@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I think your patch leaks a reference to 'x'. Move the Py_DECREF(x) to before "if (err < 0)"? And then really nitpicky: your test has 3 blank lines after it, and should have 2. Otherwise looks great. Thanks for picking this up! ---------- keywords: -needs review resolution: -> accepted stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:44:10 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 08 Dec 2008 16:44:10 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1228754650.51.0.0296744612143.issue2173@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +nelis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:48:16 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 08 Dec 2008 16:48:16 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1228754896.42.0.977782466324.issue2173@psf.upfronthosting.co.za> Mark Dickinson added the comment: Could someone please try the attached patch and see if it solves the problem. I'm not sure whether Facundo's problem is the same issue or not. ---------- keywords: +patch versions: +Python 3.1 Added file: http://bugs.python.org/file12284/issue2173.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:50:00 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 08 Dec 2008 16:50:00 +0000 Subject: [issue4592] Example patch is missing something In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228755000.86.0.0216277275439.issue4592@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In python2.6, Py_InitModule4() calls PyImport_AddModule(). Why doesn't python3.0's PyModule_Create() do the same? Index: Objects/moduleobject.c =================================================================== --- Objects/moduleobject.c (revision 67577) +++ Objects/moduleobject.c (working copy) @@ -103,8 +103,9 @@ _Py_PackageContext = NULL; } } - if ((m = (PyModuleObject*)PyModule_New(name)) == NULL) + if ((m = (PyModuleObject*)PyImport_AddModule(name)) == NULL) return NULL; + Py_INCREF(m); if (module->m_size > 0) { m->md_state = PyMem_MALLOC(module->m_size); ---------- nosy: +amaury.forgeotdarc, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:55:06 2008 From: report at bugs.python.org (David W. Lambert) Date: Mon, 08 Dec 2008 16:55:06 +0000 Subject: [issue4596] 2to3 does not fail as early as possible. In-Reply-To: <1228755306.26.0.133376435968.issue4596@psf.upfronthosting.co.za> Message-ID: <1228755306.26.0.133376435968.issue4596@psf.upfronthosting.co.za> New submission from David W. Lambert : $ #rm -f file_that_is_not_here.py $ 2to3 file_that_is_not_here.py The program spends considerable time preparing itself only to discover that it cannot open the file. ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 77327 nosy: LambertDW severity: normal status: open title: 2to3 does not fail as early as possible. type: performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:01:06 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 08 Dec 2008 17:01:06 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228755666.06.0.597090559827.issue4589@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Running the test with -R:: indeed shows the reference leak. 2nd patch with suggested corrections. ---------- assignee: jyasskin -> amaury.forgeotdarc Added file: http://bugs.python.org/file12285/with_badbool_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:01:49 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 08 Dec 2008 17:01:49 +0000 Subject: [issue2899] Fixers find, rfind, etc in 'string' module In-Reply-To: <1211027417.56.0.456898655973.issue2899@psf.upfronthosting.co.za> Message-ID: <1228755709.49.0.502996729468.issue2899@psf.upfronthosting.co.za> Armin Ronacher added the comment: 2to3 could handle it, but it would be a lot of work for something unnecessary. You can use "s.replace(a, b)" instead of string.replace(s, a, b) since at least 2.0. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:03:05 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 08 Dec 2008 17:03:05 +0000 Subject: [issue3206] Multiprocessing Array and sharedctypes.Array error in docs/implementation In-Reply-To: <1214473998.34.0.913565828871.issue3206@psf.upfronthosting.co.za> Message-ID: <1228755785.15.0.144782582056.issue3206@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- superseder: -> AssertionError in Doc/includes/mp_benchmarks.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:10:55 2008 From: report at bugs.python.org (David W. Lambert) Date: Mon, 08 Dec 2008 17:10:55 +0000 Subject: [issue2899] Fixers find, rfind, etc in 'string' module In-Reply-To: <1211027417.56.0.456898655973.issue2899@psf.upfronthosting.co.za> Message-ID: <1228756255.15.0.274151196913.issue2899@psf.upfronthosting.co.za> David W. Lambert added the comment: I think the point is to get a message from 2to3 about possible use of feature that is gone. Of course python3 raises an exception when trying to execute the code, but it does leave the user wondering "why did 2to3 report that there are no changes necessary?". _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:28:26 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 08 Dec 2008 17:28:26 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228757306.92.0.577582191604.issue4589@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Looks good. Thanks! I assume this should be merged into the 2.6.x and 3.0.x branches? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:52:13 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 08 Dec 2008 17:52:13 +0000 Subject: [issue4597] EvalFrameEx fails to set 'why' for some exceptions In-Reply-To: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za> Message-ID: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin : Several opcodes that can raise an exception fail to set x, err, or why afterward. This patch fixes all the examples I could find. I could only figure out how to write a test for PRINT_NEWLINE; the others are hard to trigger. ---------- assignee: jyasskin components: Interpreter Core files: fix_exceptions.patch keywords: needs review, patch messages: 77332 nosy: jyasskin priority: normal severity: normal stage: patch review status: open title: EvalFrameEx fails to set 'why' for some exceptions type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12286/fix_exceptions.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 19:04:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 08 Dec 2008 18:04:13 +0000 Subject: [issue4552] Doc/tools/sphinxext not included in the 2.6.1 tarball In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za> Message-ID: <1228759453.21.0.616135301492.issue4552@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, those which "make checkout" checks out :) I set this up so that nobody needs to care about any additional packages or dependencies, as long as svn is installed and working. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 19:14:07 2008 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 08 Dec 2008 18:14:07 +0000 Subject: [issue4597] EvalFrameEx fails to set 'why' for some exceptions In-Reply-To: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za> Message-ID: <1228760047.33.0.221836602358.issue4597@psf.upfronthosting.co.za> Neal Norwitz added the comment: The patch looks good. These problems also apply to 2.5 I assume? You might want to ping MvL to let him know since he's about to cut that release. ---------- keywords: -needs review nosy: +nnorwitz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 19:56:26 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 08 Dec 2008 18:56:26 +0000 Subject: [issue4597] EvalFrameEx fails to set 'why' for some exceptions In-Reply-To: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za> Message-ID: <1228762586.62.0.770497438181.issue4597@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Submitted as r67666. I'll ping Martin. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 20:01:01 2008 From: report at bugs.python.org (Kevin Watters) Date: Mon, 08 Dec 2008 19:01:01 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228762861.1.0.317576687562.issue4589@psf.upfronthosting.co.za> Changes by Kevin Watters : ---------- nosy: +kevinwatters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 20:11:43 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 08 Dec 2008 19:11:43 +0000 Subject: [issue4593] Documentation for multiprocessing - Pool.apply() In-Reply-To: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za> Message-ID: <1228763503.83.0.231299656465.issue4593@psf.upfronthosting.co.za> David M. Beazley added the comment: Actually, you shouldn't discount the potential usefulness of running apply() in all of the worker nodes. A lot of people coming from parallel programming know about things like global broadcasts, reductions, and so forth. For example, if I wanted to perform a global operation (maybe some kind of configuration) on all workers, I could see doing some kind of global apply() operation to do it. That said, I'm not actually asking for any new functionality. I'd just make it more clear that apply() is not performing a function call on all pool workers. Also, given that apply() blocks, I'm not exactly sure how useful it is in the context of actually performing work in parallel. You might want to emphasize that apply_async() is better suited for that (the only other way I could think of to take advantage of apply() in parallel would be to call it from separate threads in the process that created the pool). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:21:06 2008 From: report at bugs.python.org (Elizabeth Chang) Date: Mon, 08 Dec 2008 20:21:06 +0000 Subject: [issue4049] IDLE does not open too In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za> Message-ID: <1228767666.12.0.746427908972.issue4049@psf.upfronthosting.co.za> Elizabeth Chang added the comment: I fixed this by copying the tcl8.4 and tk8.4 directories into Python25/Lib from Python25/tcl. This fixes it but it should work without having to do this. I start new ticket and reference this one. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:22:01 2008 From: report at bugs.python.org (Elizabeth Chang) Date: Mon, 08 Dec 2008 20:22:01 +0000 Subject: [issue4598] IDLE not opening In-Reply-To: <1228767721.74.0.672735673887.issue4598@psf.upfronthosting.co.za> Message-ID: <1228767721.74.0.672735673887.issue4598@psf.upfronthosting.co.za> New submission from Elizabeth Chang : Fresh install, IDLE does not open. Cannot find tk tcl. Reference Issue4049. Problem reported in Python 2.5 and 3.0 on Windows. ---------- messages: 77338 nosy: ec2929 severity: normal status: open title: IDLE not opening versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:22:32 2008 From: report at bugs.python.org (Elizabeth Chang) Date: Mon, 08 Dec 2008 20:22:32 +0000 Subject: [issue4049] IDLE does not open too In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za> Message-ID: <1228767752.17.0.865615284358.issue4049@psf.upfronthosting.co.za> Elizabeth Chang added the comment: Issue 4598 created. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:53:26 2008 From: report at bugs.python.org (Mark Mentovai) Date: Mon, 08 Dec 2008 20:53:26 +0000 Subject: [issue3210] subprocess.Popen does not release process handles if process cannot be started In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za> Message-ID: <1228769606.46.0.22656651124.issue3210@psf.upfronthosting.co.za> Mark Mentovai added the comment: This is not limited to Windows. I experience this bug on Mac OS X and Linux as well. http://mail.python.org/pipermail/python-list/2008-August/505753.html Attachment 3210.py is a reduced testcase. It attempts to execute nocmd, which should not exist. The expected behavior is for OSError to be thrown each time, with ENOENT or EACCES set in the errno field, depending on the environment. Due to this bug, Python will hit the file descriptor limit at some point instead. For quick reproduction, set a low but reasonable limit on the number of maximum open files: mark at anodizer bash$ ulimit -n 256 mark at anodizer bash$ python 3210.py 250 Traceback (most recent call last): File "3210.py", line 11, in raise e OSError: [Errno 24] Too many open files ---------- nosy: +markmentovai Added file: http://bugs.python.org/file12287/3210.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:08:27 2008 From: report at bugs.python.org (Michael Foord) Date: Mon, 08 Dec 2008 21:08:27 +0000 Subject: [issue4599] Strings undisplayable with repr In-Reply-To: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za> Message-ID: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za> New submission from Michael Foord : In Python 3 strings with non-ascii characters are undisplayable (even with repr) in the default interactive interpreter on Windows and Mac. Shouldn't the repr use escapes as with previous versions of Python? Python 2.6 Python 2.6 (trunk:66714:66715M, Oct 1 2008, 18:36:04) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> d = u'\u20ac' >>> d u'\u20ac' Python 3 Python 3.0 (r30:67503, Dec 6 2008, 21:14:27) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> d = '\u20ac' >>> d Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/io.py", line 1491, in write b = encoder.encode(s) File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/encodings/ascii.py", line 22, in encode return codecs.ascii_encode(input, self.errors)[0] UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 1: ordinal not in range(128) >>> repr(d) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/io.py", line 1491, in write b = encoder.encode(s) File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/encodings/ascii.py", line 22, in encode return codecs.ascii_encode(input, self.errors)[0] UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 2: ordinal not in range(128) >>> ---------- components: Interpreter Core, Macintosh, Windows messages: 77341 nosy: mfoord severity: normal status: open title: Strings undisplayable with repr versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:08:59 2008 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 08 Dec 2008 21:08:59 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <1228770539.76.0.651168438885.issue4587@psf.upfronthosting.co.za> Roumen Petrov added the comment: I confirm my expectation: in case 'elif cand == "gdbm":' the if statement for "gdbm.h" has to be removed. This header don't provide dbm/ndbm compatible structure/function names. If setup is without 'if find_file("gdbm.h"...' statement dbm module is build successfully and test_dbm pass. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:25:22 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Dec 2008 21:25:22 +0000 Subject: [issue4600] __class__ assignment: new-style? heap? == confusing In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za> Message-ID: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za> New submission from Terry J. Reedy : ob.__class__ = ob2 gives some confusing TypeError messages. >>> c.__class__ = 1 Traceback (most recent call last): File "", line 1, in TypeError: __class__ must be set to new-style class, not 'int' object Problem: 'new-style' is obsolete in 3.0. It is also too inclusive... >>> c.__class__ = object Traceback (most recent call last): File "", line 1, in TypeError: __class__ assignment: only for heap types object *is* 'new-style'. I presume 'heap type' means 'class defined by class statement'. If so, let us say so, since beginning programmers may not know what a 'heap type' is. If the above is incorrect, then this experienced programmer also does not know what it means in Python context ;-). Proposal: when someone tries to set __class__ to an inappropriate object, give similar error message for instances and heap classes. TypeError: __class__ must be set to a class defined by a class statement, not 'xxx' [object]. where 'object', without the brackets, is added for non-classes, as it is today. >>> c.__class__ = object Traceback (most recent call last): File "", line 1, in TypeError: __class__ assignment: only for heap types C, the class of c, *is* a heap type. The different problem, the target being an instance of heap class, should get a different message. 'Heap' is still possibly confusing. Proposal: TypeError: __class__ assignment: only for instances of classes defined by class statements. ---------- components: Interpreter Core messages: 77343 nosy: tjreedy severity: normal status: open title: __class__ assignment: new-style? heap? == confusing type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:27:53 2008 From: report at bugs.python.org (Leger) Date: Mon, 08 Dec 2008 21:27:53 +0000 Subject: [issue4601] permissions errors with altinstall in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> New submission from Leger : Under Debian/Lenny, with Python3.0.final install from the tarball, any user can't import lib-dynload, launch IDLE ... but local root can do them. When I login in root and run "chmod -R o+rx /usr/lib/python3.0/*", users can use normaly python3.0. Install detail : "configure --with-pydebug --with-doc-strings --enable-shared --enable-profiling --enable-ipv6 --with-threads --with-tsc --prefix=/usr ; make ; make test" and after "make altinstall > altinstall.log 2>&1". I join altinstall.log. ---------- components: Library (Lib) files: altinstall.log messages: 77344 nosy: legerf severity: normal status: open title: permissions errors with altinstall in 3.0 type: resource usage versions: Python 3.0 Added file: http://bugs.python.org/file12288/altinstall.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:30:02 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 08 Dec 2008 21:30:02 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228771802.23.0.877789015579.issue1717@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Instead of removing cmp(a, b) and replacing all uses with (a>b)-(b _______________________________________ From report at bugs.python.org Mon Dec 8 22:30:31 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 08 Dec 2008 21:30:31 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228771831.11.0.222917173428.issue4335@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: In order to reproduce the reported problem I had to conjure the attached repro.py which is missing '\n' on the last line. I need to double check the language definition, but I feel this is not a bug because a file that ends with an unterminated line is not a well- formed python program. Added file: http://bugs.python.org/file12289/repro.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:37:24 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 08 Dec 2008 21:37:24 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228772244.68.0.596356945275.issue4335@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: According to my understanding of http://docs.python.org/reference/lexical_analysis.html#id1 a newline character is required at the end of the python file. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:38:29 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Dec 2008 21:38:29 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <1228770539.76.0.651168438885.issue4587@psf.upfronthosting.co.za> Message-ID: <18749.37837.856871.163969@montanaro-dyndns-org.local> Skip Montanaro added the comment: Roumen> I confirm my expectation: Roumen> in case 'elif cand == "gdbm":' the if statement for "gdbm.h" has to be Roumen> removed. This header don't provide dbm/ndbm compatible Roumen> structure/function names. Roumen> If setup is without 'if find_file("gdbm.h"...' statement dbm module is Roumen> build successfully and test_dbm pass. Right. Dumb move on my part. New patch attached. Skip Added file: http://bugs.python.org/file12290/setup.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.diff URL: From report at bugs.python.org Mon Dec 8 22:38:51 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 08 Dec 2008 21:38:51 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228772331.12.0.847514394384.issue1717@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:38:54 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Dec 2008 21:38:54 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <1228772334.76.0.0639667407149.issue4587@psf.upfronthosting.co.za> Changes by Skip Montanaro : Removed file: http://bugs.python.org/file12275/setup.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:42:11 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Mon, 08 Dec 2008 21:42:11 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za> Message-ID: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za> New submission from Adeodato Sim? : Hello, after using 2to3 --write over some scripts, I found it very cumbersome having to run `chmod +x` on each of them afterwards. The attached patch is a possible way to fix this issue. It'd be great if somebody could apply it, or write a more appropriate fix. ---------- components: 2to3 (2.x to 3.0 conversion tool) files: 2to3_preserve_mode.diff keywords: patch messages: 77349 nosy: dato severity: normal status: open title: 2to3 drops executable bit with --write versions: Python 3.0 Added file: http://bugs.python.org/file12291/2to3_preserve_mode.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:56:16 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 21:56:16 +0000 Subject: [issue4555] Smelly exports In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> Message-ID: <1228773376.57.0.219872456916.issue4555@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I guess you *could* change the name of extensions that become builtin modules. However, I think it is not worth the trouble, especially since PEP 3121 solves the problem for good, for Python 3. I propose to simply filter out init[_a-z]+ from the set of "bad" symbols. That leaves us with asdl_*_seq_new, and _add_one_to_index_; the latter is already reported as issue3101. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:59:56 2008 From: report at bugs.python.org (Leger) Date: Mon, 08 Dec 2008 21:59:56 +0000 Subject: [issue4601] permissions errors with altinstall in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228773596.27.0.17214687429.issue4601@psf.upfronthosting.co.za> Leger added the comment: My root umask = 0027 (hardened system), so the altinstall/install script don't manage umask parameter. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:06:52 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Mon, 08 Dec 2008 22:06:52 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za> Message-ID: <1228774012.12.0.651259909269.issue4602@psf.upfronthosting.co.za> Changes by Adeodato Sim? : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:10:09 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2008 22:10:09 +0000 Subject: [issue4601] permissions errors with altinstall in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228774209.81.0.534836102583.issue4601@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm able to reproduce the bug with umask set to 0027: drwxr-x--- 2 root root 3072 d?c 8 22:59 (...)/lib/python3.1/lib-dynload With umask 0077, it's: drwx------ 2 root root 3072 d?c 8 22:59 (...)/lib/python3.1/lib-dynload The problem is specific to this directory. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:10:27 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 22:10:27 +0000 Subject: [issue3101] global function _add_one_to_index_C In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za> Message-ID: <1228774227.52.0.711475790166.issue3101@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- title: global function _add_one_to_C -> global function _add_one_to_index_C _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:12:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 22:12:25 +0000 Subject: [issue3101] global function _add_one_to_index_C In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za> Message-ID: <1228774345.5.0.55250929869.issue3101@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think _add_one_to_index_C and _add_one_to_index_F should be renamed. If they are meant to be called by non-core extension modules, their names should start with Py_, else with _Py_. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:27:57 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2008 22:27:57 +0000 Subject: [issue4601] permissions errors with altinstall in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228775277.62.0.584765745509.issue4601@psf.upfronthosting.co.za> STINNER Victor added the comment: install() method of the install_lib command (Lib/distutils/command/install_lib.py) calls self.copy_tree() which calls copy_tree() from Lib/distutils/dir_util.py. By default, this function preserve the modes (perserve_mode=1 by default). Or the build created a directory with permissions "drwx------". I wrote that only lib-dynload directory has a problem. But other files are install with permissions -rw-------: - .../lib/python?.?/*.{pyc,pyo} - .../lib/python?.?/lib2to3/PatternGrammar*.pickle - .../lib/python?.?/lib2to3/Grammar*.pickle - .../lib/python?.?/lib-dynload/Python*.egg-info ---------- components: +Distutils -Library (Lib) versions: +Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:35:51 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2008 22:35:51 +0000 Subject: [issue4591] uid/gid problem in os.chown In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> Message-ID: <1228775751.09.0.726835862848.issue4591@psf.upfronthosting.co.za> STINNER Victor added the comment: 2^31-2 doesn't fit in long on 32 bits CPU. On my Linux box, uid_t is an unsigned integer (32 bits unsigned integer). Why not using "unsigned int"? chown prototype: int chown(const char *path, uid_t owner, gid_t group); ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:38:50 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2008 22:38:50 +0000 Subject: [issue4601] permissions errors with altinstall in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228775930.29.0.49851430126.issue4601@psf.upfronthosting.co.za> STINNER Victor added the comment: With Python trunk, the directory has the right permission (drwxr-xr-x) whereas build/lib.linux(...) has permission drwx------. But the problem is still open for listed files (.pyc, .pyo, .picle, .egg-info). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:40:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 22:40:22 +0000 Subject: [issue4594] Can't compile with -O3, on ARM, with gcc 3.4.4 In-Reply-To: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za> Message-ID: <493DA253.4000209@v.loewis.de> Martin v. L?wis added the comment: > Now, this isn't really Python's fault; gcc really shouldn't be crashing. > However, it'd be nice if configure had a way to specify the > optimization level--I had to go in and edit the generated Makefile by > hand. Well, Python does have a way - the way you have been using. However, as yet another way, you can set the OPT environment variable, to define the optimization flags to be used (and other non-essential compiler flags). > Better yet would be if configure could recognize the platform and > set the -O level accordingly. I'm opposed. Selecting such a thing by platform and compiler version is too transient to be maintainable. It would be different if the platform would have been around for 10 years, and had seen no compiler change for 8 years, but in this case, this likely is fixed before the next Python release is even made. Please report this to the system vendor. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:58:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 22:58:49 +0000 Subject: [issue4597] EvalFrameEx fails to set 'why' for some exceptions In-Reply-To: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za> Message-ID: <1228777129.53.0.8104261555.issue4597@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is fine to port to 2.5; please go ahead. Don't forget to add Misc/NEWS entries, though - also add them for the branches you have changed already. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:03:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 23:03:39 +0000 Subject: [issue4598] IDLE not opening In-Reply-To: <1228767721.74.0.672735673887.issue4598@psf.upfronthosting.co.za> Message-ID: <1228777419.15.0.4177651652.issue4598@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Do you have TCL_LIBRARY or TK_LIBRARY environment variables set? This is a very obscure behavior - the installer is known to work on many machines, including IDLE. So something must be particular with your Windows installation. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:05:51 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Dec 2008 23:05:51 +0000 Subject: [issue4603] 3.0 document tab interpretation change In-Reply-To: <1228777550.97.0.72005547671.issue4603@psf.upfronthosting.co.za> Message-ID: <1228777550.97.0.72005547671.issue4603@psf.upfronthosting.co.za> New submission from Terry J. Reedy : In 2.6, Ref Manual / Lexical Analysis / Indentation says "First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix). The total number of spaces preceding the first non-blank character then determines the line?s indentation. " and Using Python / Command line / Misc options says "-t Issue a warning when a source file mixes tabs and spaces for indentation in a way that makes it depend on the worth of a tab expressed in spaces. Issue an error when the option is given twice (-tt)." Inyeol Lee, on c.l.p., in response to a report of a TabError, says "-tt option in python 2.x is now default in python 3.0. Apparently it got slipped from any documentation, including what's new." In 3.0 docs, the -t option *was* removed from Using Python, but the Indentation sentences quoted above remain unchanged, though obsolete. I would guess that they should be replaced by something like "When a source file mixes tabs and spaces for indentation in a way that makes it depend on the worth of a tab expressed in spaces, a TabError is raised." Perhaps What's New should get a sentence too. "The former -tt startup option to raise TabError on ambiguous mixtures of tabs and spaces for indentation has been removed as an option and is now the standard behavior." ---------- assignee: georg.brandl components: Documentation messages: 77360 nosy: georg.brandl, tjreedy severity: normal status: open title: 3.0 document tab interpretation change versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:12:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 08 Dec 2008 23:12:28 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228777948.56.0.25483578685.issue1717@psf.upfronthosting.co.za> Christian Heimes added the comment: Marc-Andre, how do you like a function PyUnicode_Equal() instead of PyUnicode_Compare()? The old PyUnicode_Compare() function returns -1 for smaller value and errors, 0 for equality and +1 for larger value. I find it confusing to have one function that follows the old PyObject_Compare() behavior. Instead I'm proposing PyUnicode_Equal() which returns -1 for errors, 0 for unequal and +1 for equal. The function follows the semantic of http://docs.python.org/c-api/object.html#PyObject_RichCompareBool nicely. About your proposal for cmp(), where should we put the method? I'm -0.5 on builtins. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:13:07 2008 From: report at bugs.python.org (Forest Wilkinson) Date: Mon, 08 Dec 2008 23:13:07 +0000 Subject: [issue1533164] Installed but not listed *.pyo break bdist_rpm Message-ID: <1228777987.86.0.457769915686.issue1533164@psf.upfronthosting.co.za> Changes by Forest Wilkinson : ---------- nosy: +forest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:22:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 23:22:13 +0000 Subject: [issue4599] Strings undisplayable with repr In-Reply-To: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za> Message-ID: <1228778533.8.0.245129337571.issue4599@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This specific character shouldn't be undisplayable on Windows, not even on your version of Windows. Instead, Python should find out how to convert it to your terminal's encoding, rather than using ASCII. It's a bug that the OSX port using ASCII; it probably should use UTF-8 by default for the terminal encoding. In any case, it is *not* a bug that Python doesn't escape the character. If you want it escaped, use the ascii() builtin function. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:28:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Dec 2008 23:28:12 +0000 Subject: [issue3101] global function _add_one_to_index_C In-Reply-To: <1228774345.5.0.55250929869.issue3101@psf.upfronthosting.co.za> Message-ID: <1228778890.27610.0.camel@localhost> Antoine Pitrou added the comment: I think they currently are private functions which happen to be used accross two different C source files. So they should be renamed _Py_something (or the situation should be fixed so that they can be made static). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:34:10 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2008 23:34:10 +0000 Subject: [issue4601] directory permission error with make install in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228779250.93.0.546826407504.issue4601@psf.upfronthosting.co.za> STINNER Victor added the comment: Gotcha! os.path.walk() was replaced by os.walk() but walk() argument is no more a callback because walk() is a generator! Here is a fix. ---------- keywords: +patch title: permissions errors with altinstall in 3.0 -> directory permission error with make install in 3.0 versions: -Python 2.6, Python 2.7 Added file: http://bugs.python.org/file12292/setup_chmod.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:38:02 2008 From: report at bugs.python.org (Michael Foord) Date: Mon, 08 Dec 2008 23:38:02 +0000 Subject: [issue4599] Strings undisplayable with repr In-Reply-To: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za> Message-ID: <1228779482.93.0.91455802417.issue4599@psf.upfronthosting.co.za> Michael Foord added the comment: Hmmm... nope - my terminal encoding (according to Python) on WIndows Vista x64 (with 32bit Python and a vanilla cmd) is cp850. C:\compile>C:\Python30\python.exe Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> '\u20ac' Traceback (most recent call last): File "", line 1, in File "C:\Python30\lib\io.py", line 1491, in write b = encoder.encode(s) File "C:\Python30\lib\encodings\cp850.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_map)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\u20ac' in position 1: character maps to Oh well. (The traceback I posted was from Max OS X 10.5 - I didn't dig closely enough to see that a different encoding was being used on Windows, my bad - and thanks for the tip about ascii() ). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:40:53 2008 From: report at bugs.python.org (Michael Foord) Date: Mon, 08 Dec 2008 23:40:53 +0000 Subject: [issue4599] Strings undisplayable with repr In-Reply-To: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za> Message-ID: <1228779653.67.0.471066613518.issue4599@psf.upfronthosting.co.za> Michael Foord added the comment: OK - and as a further follow up, the traceback I posted for Mac OS X was from a terminal called iTerm. I tried the same thing on the standard 'Terminal' app and it prints the Euro symbol fine. Looks like iTerm is an ascii terminal. Sorry for the noise, I think this can be closed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:41:30 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Dec 2008 23:41:30 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228779690.06.0.59391056206.issue4580@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is patch, using the "small storage at the end of Py_buffer" idea. It adds a lot of unit tests as well. ---------- keywords: +needs review, patch stage: test needed -> patch review Added file: http://bugs.python.org/file12293/issue4580.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:44:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 23:44:49 +0000 Subject: [issue3101] global function _add_one_to_index_C In-Reply-To: <1228778890.27610.0.camel@localhost> Message-ID: <493DB16F.4080002@v.loewis.de> Martin v. L?wis added the comment: > I think they currently are private functions which happen to be used > accross two different C source files. But see msg71879 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:46:17 2008 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 08 Dec 2008 23:46:17 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228779977.48.0.769886492348.issue4558@psf.upfronthosting.co.za> Roumen Petrov added the comment: Socket module need to be patched too otherwise test_socket fail on UNIX domain socket tests. After clean build and with new patch the regression tests results are: 337 tests OK. 3 tests failed: test_curses test_urllib2_localnet test_urllibnet 21 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_kqueue test_macos test_macostools test_pep277 test_py3kwarn test_scriptpackages test_sqlite test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. Interesting for failed tests is that every succeed if run independently. Added file: http://bugs.python.org/file12294/python-trunk-20081209-c89.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:46:24 2008 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 08 Dec 2008 23:46:24 +0000 Subject: [issue4558] with_stdc89 In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za> Message-ID: <1228779984.82.0.0550446774015.issue4558@psf.upfronthosting.co.za> Changes by Roumen Petrov : Removed file: http://bugs.python.org/file12253/python-trunk-20081206-c89.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:46:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 23:46:32 +0000 Subject: [issue4599] Strings undisplayable with repr In-Reply-To: <1228779482.93.0.91455802417.issue4599@psf.upfronthosting.co.za> Message-ID: <493DB1D6.8040804@v.loewis.de> Martin v. L?wis added the comment: > Hmmm... nope - my terminal encoding (according to Python) on WIndows > Vista x64 (with 32bit Python and a vanilla cmd) is cp850. Ah, ok. That doesn't have the euro sign, either. Try it in IDLE, though. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:46:54 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Dec 2008 23:46:54 +0000 Subject: [issue4599] Strings undisplayable with repr In-Reply-To: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za> Message-ID: <1228780014.28.0.735942039756.issue4599@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:52:49 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Dec 2008 23:52:49 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228780369.41.0.499582675724.issue1717@psf.upfronthosting.co.za> Antoine Pitrou added the comment: IMO PyUnicode_Compare() should be replaced by a hypothetical PyObject_RichCompare(), which allows to take shortcuts when comparing strings of different length and a Py_EQ or Py_NE comparison is requested. (see #3106 too) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:53:23 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 08 Dec 2008 23:53:23 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1228777948.56.0.25483578685.issue1717@psf.upfronthosting.co.za> Message-ID: <493DB370.4010104@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-09 00:12, Christian Heimes wrote: > Christian Heimes added the comment: > > Marc-Andre, how do you like a function PyUnicode_Equal() instead of > PyUnicode_Compare()? > > The old PyUnicode_Compare() function returns -1 for smaller value and > errors, 0 for equality and +1 for larger value. I find it confusing to > have one function that follows the old PyObject_Compare() behavior. For Unicode objects you don't have the issues with general rich comparisons. Unicode objects only know <, = and >, so the C approach of using -1, 0, +1 for these results will work just fine. It doesn't in the general case, where comparisons can return arbitrary objects. > Instead I'm proposing PyUnicode_Equal() which returns -1 for errors, 0 > for unequal and +1 for equal. The function follows the semantic of > http://docs.python.org/c-api/object.html#PyObject_RichCompareBool nicely. Yes, but for sorting Unicode (in C) and other quick checks that rely on lexical ordering you need checks for < and > as well. It's better to have just one C API than 3 or 5 to cover all comparison cases. > About your proposal for cmp(), where should we put the method? I'm -0.5 > on builtins. Good question. It is in the builtins in Python 2.x, so keeping it there would make porting easier, but then it's probably better to put it somewhere else to make people aware of the fact that the underlying machinery has changed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:53:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Dec 2008 23:53:42 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228780422.48.0.269155734054.issue4580@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +teoliphant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:55:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Dec 2008 23:55:36 +0000 Subject: [issue3101] global function _add_one_to_index_C In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za> Message-ID: <1228780536.87.0.135558171304.issue3101@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, then a proper API should be devised. Perhaps Travis can shed more light on what he thinks would be useful. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:58:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Dec 2008 23:58:56 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1228780369.41.0.499582675724.issue1717@psf.upfronthosting.co.za> Message-ID: <1228780732.27610.2.camel@localhost> Antoine Pitrou added the comment: I wrote: > IMO PyUnicode_Compare() should be replaced by a hypothetical > PyObject_RichCompare(), which allows to take shortcuts when comparing > strings of different length and a Py_EQ or Py_NE comparison is requested. ... and I didn't even remember that PyUnicode_RichCompare() already exists. So let my proposal be to enable those optimizations inside the existing PyUnicode_RichCompare(), and dump PyUnicode_Compare(). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:10:36 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 09 Dec 2008 00:10:36 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1228780732.27610.2.camel@localhost> Message-ID: <493DB779.40802@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-09 00:58, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > I wrote: >> IMO PyUnicode_Compare() should be replaced by a hypothetical >> PyObject_RichCompare(), which allows to take shortcuts when comparing >> strings of different length and a Py_EQ or Py_NE comparison is requested. > > ... and I didn't even remember that PyUnicode_RichCompare() already > exists. So let my proposal be to enable those optimizations inside the > existing PyUnicode_RichCompare(), and dump PyUnicode_Compare(). What for ? What does this have to do with removing __cmp__ ? Why do you want to break the C API for no apparent reason ? I've designed the Unicode C API to be a rich API and would like it to stay that way. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:11:21 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 00:11:21 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> New submission from Skip Montanaro : Seems like file.close() in 3.0 isn't much of a barrier to further reading: % python3.0 Python 3.0rc3+ (py3k:67338M, Nov 22 2008, 06:47:23) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> fp = open("/etc/services") >>> ct = fp.read(1048) >>> print (ct[-80:], end='') ; fp.close() ; ct = fp.read(17) ; print (ct) compressnet 2/udp # Management Utility compressnet 2/tcp # Management Utility The second read() should raise an exception. Same code, 2.6: % python2.6 Python 2.6+ (release26-maint:66821:66833, Oct 30 2008, 22:16:1) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import print_function >>> fp = open("/etc/services") >>> ct = fp.read(1048) >>> print (ct[-80:], end='') ; fp.close() ; ct = fp.read(17) ; print (ct) compressnet 2/udp # Management Utility Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file compressnet 2/tcp # M>>> Culled this from a posting to comp.lang.python. ---------- components: Interpreter Core messages: 77376 nosy: skip.montanaro severity: normal status: open title: close() seems to have limited effect type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:20:22 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 00:20:22 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228782022.03.0.632726252073.issue4574@psf.upfronthosting.co.za> STINNER Victor added the comment: The bug is in IncrementalNewlineDecoder, not in the codec nor TextIOWrapper. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:24:06 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 00:24:06 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228782246.18.0.818761124939.issue4574@psf.upfronthosting.co.za> STINNER Victor added the comment: Smaller example to demonstrate the problem. Added file: http://bugs.python.org/file12295/dec.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:24:44 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 00:24:44 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228782284.17.0.247097553745.issue4574@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file12295/dec.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:25:11 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 00:25:11 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228782311.29.0.00612142988193.issue4574@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file12296/incremental_newline_decoder_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:30:29 2008 From: report at bugs.python.org (chris) Date: Tue, 09 Dec 2008 00:30:29 +0000 Subject: [issue4605] 3.0 documentation mentions using maketrans from within the string module. In-Reply-To: <1228782629.1.0.4913210804.issue4605@psf.upfronthosting.co.za> Message-ID: <1228782629.1.0.4913210804.issue4605@psf.upfronthosting.co.za> New submission from chris : http://docs.python.org/3.0/library/stdtypes.html#str.translate mentions the following: "You can use the maketrans() helper function in the string module to create a translation table." But maketrans is now a string method not just a function of the string module. It even mentions that right above it that it is now a method of string objects: "A map for translate() is usually best created by str.maketrans()." The page where this all appears in is: http://docs.python.org/3.0/library/stdtypes.html It may have just not been updated fully from an older release. If I am mistaken and this is not a bug, I appologise. ---------- assignee: georg.brandl components: Documentation messages: 77379 nosy: georg.brandl, suicideducky severity: normal status: open title: 3.0 documentation mentions using maketrans from within the string module. versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:52:17 2008 From: report at bugs.python.org (Rafe Sacks) Date: Tue, 09 Dec 2008 00:52:17 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228783937.01.0.950871119369.issue4335@psf.upfronthosting.co.za> Rafe Sacks added the comment: "I feel this is not a bug because a file that ends with an unterminated line is not a well-formed python program." I used Komodo to make the file. Nothing special. I just made a new python document and used it. If there is a Komodo Bug that is fine, but if this issue can happen (and it has), then the module should be made more robust to protect against it happening, shouldn't it? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:59:48 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 09 Dec 2008 00:59:48 +0000 Subject: [issue4600] __class__ assignment: new-style? heap? == confusing In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za> Message-ID: <1228784388.93.0.839122686872.issue4600@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Related issue that applies to recent 2.x. Language/data model/Objects, values, and types says 'An object?s type is also unchangeable.'. This should be changed or deleted. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 02:53:28 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 01:53:28 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228787608.66.0.784216401858.issue4574@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch for test_io.py: check the problem by adding new encodings to TextIOWrapperTest.testNewlines(). ---------- keywords: +patch Added file: http://bugs.python.org/file12297/test_io.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 02:55:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 09 Dec 2008 01:55:47 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228787747.41.0.885206379005.issue4604@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules, Library (Lib) -Interpreter Core nosy: +christian.heimes priority: -> release blocker stage: -> test needed versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 02:58:36 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 09 Dec 2008 01:58:36 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za> Message-ID: <1228787916.58.0.49206821132.issue4602@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67674. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 03:08:27 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 02:08:27 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1228788507.08.0.853716539366.issue4574@psf.upfronthosting.co.za> STINNER Victor added the comment: Ugly patch to fix this issue: - add more regression tests for charsets UTF-16*, UTF-32* - add mandatory argument "encoding" to io.IncrementalNewlineDecoder constructor => BREAK THE API - use the encoding the encode "\r" - most ulgy hack: strip the BOM for codecs "UTF-16" and "UTF-32" (when encoding "\r" to bytes) => I don't know how to encode "\r" without the BOM Added file: http://bugs.python.org/file12298/incremental_newline_decoder-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 03:12:06 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 09 Dec 2008 02:12:06 +0000 Subject: [issue4596] 2to3 does not fail as early as possible. In-Reply-To: <1228755306.26.0.133376435968.issue4596@psf.upfronthosting.co.za> Message-ID: <1228788726.21.0.558133282991.issue4596@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I'm tempted to close this as a "won't fix". For 99.9% of cases, it would only be annoying to check for the presence of a file before starting up. ---------- nosy: +benjamin.peterson priority: -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 03:12:19 2008 From: report at bugs.python.org (Paul Winkler) Date: Tue, 09 Dec 2008 02:12:19 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1228788739.24.0.548050323227.issue1180@psf.upfronthosting.co.za> Paul Winkler added the comment: Whatever happened with this? I don't see it mentioned in the NEWS file for the 2.6 line. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 03:14:38 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 09 Dec 2008 02:14:38 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228788878.84.0.572460240674.issue4335@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Rafe, Can you confirm that behavior on missing end-of-line is indeed your issue? Note that at first I could not even reproduce the problem based on your report. I am attaching a proof-of-concept patch that would arguably improve the inspect module by making it more robust in your case. Note that it is unlikely that a fix along the lines of my patch will be considered for bug-fix releases of 2.5.x and 2.6.x series. If you want an immediate solution, you have a better chance convincing Komodo developers to fix their text editor (emacs' python mode auto-terminates the last line in .py files.) ---------- keywords: +patch Added file: http://bugs.python.org/file12299/inspect.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 03:47:01 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 02:47:01 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228790821.77.0.151169452651.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It is in the builtins in Python 2.x, so keeping it there would make > porting easier, but then it's probably better to put it somewhere else > to make people aware of the fact that the underlying machinery has > changed. from __past__ import cmp ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 04:53:42 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 09 Dec 2008 03:53:42 +0000 Subject: [issue4590] 2to3 strips trailing L for long iterals in two fixers In-Reply-To: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za> Message-ID: <1228794822.7.0.738706443057.issue4590@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think this is the correct thing to do. Go ahead. (Did you see if any of the long tests would be applicable in testing numliterals?) ---------- assignee: benjamin.peterson -> aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 07:54:51 2008 From: report at bugs.python.org (Armin Ronacher) Date: Tue, 09 Dec 2008 06:54:51 +0000 Subject: [issue4590] 2to3 strips trailing L for long iterals in two fixers In-Reply-To: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za> Message-ID: <1228805691.38.0.206323797301.issue4590@psf.upfronthosting.co.za> Armin Ronacher added the comment: Patch applied in [67679]. The tests were nearly the same, even with the same numbers :) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 07:55:00 2008 From: report at bugs.python.org (Armin Ronacher) Date: Tue, 09 Dec 2008 06:55:00 +0000 Subject: [issue4590] 2to3 strips trailing L for long iterals in two fixers In-Reply-To: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za> Message-ID: <1228805700.01.0.844685265792.issue4590@psf.upfronthosting.co.za> Changes by Armin Ronacher : ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 08:30:27 2008 From: report at bugs.python.org (David W. Lambert) Date: Tue, 09 Dec 2008 07:30:27 +0000 Subject: [issue4596] 2to3 does not fail as early as possible. In-Reply-To: <1228755306.26.0.133376435968.issue4596@psf.upfronthosting.co.za> Message-ID: <1228807827.81.0.960413551159.issue4596@psf.upfronthosting.co.za> David W. Lambert added the comment: Granted, this isn't the hottest issue circulating. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 08:58:06 2008 From: report at bugs.python.org (Zsolt Haraszti) Date: Tue, 09 Dec 2008 07:58:06 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228809486.15.0.16851144522.issue4335@psf.upfronthosting.co.za> Zsolt Haraszti added the comment: We are also using inspect.getsourceline() in a large system at my company and we observed some unreliable behavior in the past which we never had time to analyze till today. Interesting coincidence, but today we finally took the effort and traced the issue, and we found that: getsourceline() does not report the last line of a class definition body _IF_: (1) that line is the last line of the file, _AND_ (2) that line is not terminated with a newline (\n) This also answers Alexandre's question: yes, the problem happens only if the line is unterminated. I understand that an unterminated line may be non-conforming per Python specs, but my WingIDE happily saved the file, so I suspect other editors may just do the same, and I do agree with Rafe that it would be nice if inspect would be resilient against the missing \n. I assume there would be no harm, and it could eliminate some angst (it is really not obvious first why it fails). I would really love to see this fixed in a patch release on the 2.5+ lines. Any chance? ---------- nosy: +zsolt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:25:12 2008 From: report at bugs.python.org (Sjoerd Mullender) Date: Tue, 09 Dec 2008 08:25:12 +0000 Subject: [issue4591] uid/gid problem in os.chown In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> Message-ID: <1228811112.38.0.120918625941.issue4591@psf.upfronthosting.co.za> Sjoerd Mullender added the comment: I'm sure you meant 2^32-2 ;-). The "fix" to use long doesn't seem right to me either. unsigned int is a better match with uid_t and gid_t. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:29:46 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 09 Dec 2008 08:29:46 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228811386.87.0.178570105831.issue4589@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch doesn't apply cleanly to the 2.5 branch, because that doesn't have r61290. If somebody wants to backport it, go ahead (if you can do so by Thursday). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:59:50 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2008 08:59:50 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228813190.52.0.916898681593.issue4589@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Does it need to be backported to 2.5? IMO it is a corner case. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 10:03:12 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 09 Dec 2008 09:03:12 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1228813392.17.0.723741437671.issue4512@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 10:22:46 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 09:22:46 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228814566.43.0.874157787344.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: More seriously, if cmp were to go into the standard library somewhere, perhaps Raymond's class decorator (for filling in missing rich comparisons) could go into the same place? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 10:47:00 2008 From: report at bugs.python.org (Robert Luce) Date: Tue, 09 Dec 2008 09:47:00 +0000 Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za> Message-ID: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za> New submission from Robert Luce : Consider the library 'c_lib.so' consisting of a single function 'c_func' int c_func ( double *arg0, double *arg1, double *arg2, double *arg3, double *arg4, double *arg5, double *arg6) { printf("Value of arg0 is %p\n", arg0); printf("Value of arg1 is %p\n", arg1); printf("Value of arg2 is %p\n", arg2); printf("Value of arg3 is %p\n", arg3); printf("Value of arg4 is %p\n", arg4); printf("Value of arg5 is %p\n", arg5); printf("Value of arg6 is %p\n", arg6); return 0; } and the following snippet: from ctypes import * c_lib = CDLL('c_lib.so') t = POINTER(c_double) c_lib.c_func.argtypes = [t,t,t,t,t,t,t] def call_c_func(): nptr = None c_lib.c_func(nptr, nptr, nptr, nptr, nptr, nptr, nptr) The output I get from call_c_func() with Python 2.6 and Python 2.5 on a 64 bit Linux box is (it probably won't happen on 32 bit systems): Value of arg0 is (nil) Value of arg1 is (nil) Value of arg2 is (nil) Value of arg3 is (nil) Value of arg4 is (nil) Value of arg5 is (nil) Value of arg6 is 0xa00000000 The reason appears to be that in 'PointerType_from_param' (_ctypes.c) Py_None is converted to a Python integer of value 0. Later, in 'ConvParam' (callproc.c), this integer ends up as a 4 byte integer type on the argument stack for ffi. I don't know anything about ffi, but this looks at least suspicious on any platform where sizeof(void*) is 8. I propose to remove NULL pointer handling from the above from_param function, since Py_None is properly handled by ConvParam itself. A patch against the 2.6 maintenance branch is attached. ---------- assignee: theller components: ctypes files: patch_ctypes_none_arg.diff keywords: patch messages: 77397 nosy: robertluce, theller severity: normal status: open title: Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file12300/patch_ctypes_none_arg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 10:59:18 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2008 09:59:18 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228816758.56.0.395743984917.issue1717@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Moving cmp() somewhere other than builtins is not progress. IMO, it needs to die off and the concept of it needs to disappear completely. Code is better without it. Three-way comparisons are PITA to use -- their only virtue is as an optimization in the few cases where one three-way test is cheaper to compute than two two-way tests. The goal for 3.0 was to have one way to do it and thereby simplify the language. Tucking it away in a module or writing a new decorator defeats the purpose. It simply should die and go away. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:09:32 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 10:09:32 +0000 Subject: [issue4591] 32-bits unsigned user/group identifier In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> Message-ID: <1228817372.24.0.328257712682.issue4591@psf.upfronthosting.co.za> STINNER Victor added the comment: There is not only chown! There are also lchown(), fchown(), stat() and lstat(). Attached patch: - use "unsigned int" to store Windows st_uid/st_gid in the win32_stat structure - use PyLong to store an unsigned group in the stat result (because 2^32-2 doesn't fit in a PyInt) - use "unsigned int" (instead of long) for uid/gid in chown, lchown and fchown Note: *chown() accepts -1 for an argument, eg. chown("file", 10, -1) only changes the user group. ---------- title: uid/gid problem in os.chown -> 32-bits unsigned user/group identifier versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12301/posix_unsigned_uid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:13:27 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 10:13:27 +0000 Subject: [issue4591] 32-bits unsigned user/group identifier In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> Message-ID: <1228817607.58.0.295776947626.issue4591@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested my patch (for Python trunk) on Ubuntu Gutsy with a 32 bits CPU: chown(), lchwon(), fchown(), stat() and lstat() works as expected (support identifier > 2**31-1). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:13:33 2008 From: report at bugs.python.org (Morten Bentsen) Date: Tue, 09 Dec 2008 10:13:33 +0000 Subject: [issue4607] uuid behavior with multiple threads In-Reply-To: <1228817613.61.0.835491086026.issue4607@psf.upfronthosting.co.za> Message-ID: <1228817613.61.0.835491086026.issue4607@psf.upfronthosting.co.za> New submission from Morten Bentsen : The uuid module uses a single global buffer for storing random values obtained from the system. This can (and does) cause non-uniqueness of generated id's when using the uuid4 function in a multithreaded program. The following snippet shows the problem - _buffer is the global buffer: # When the system provides a version-4 UUID generator, use it. if _uuid_generate_random: _uuid_generate_random(_buffer) return UUID(bytes=_buffer.raw) ---------- components: Library (Lib) messages: 77401 nosy: mortenab severity: normal status: open title: uuid behavior with multiple threads type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:32:01 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 10:32:01 +0000 Subject: [issue4607] uuid behavior with multiple threads In-Reply-To: <1228817613.61.0.835491086026.issue4607@psf.upfronthosting.co.za> Message-ID: <1228818721.23.0.00286318916362.issue4607@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like the bug is already fixed in Python trunk: def uuid4(): """Generate a random UUID.""" # When the system provides a version-4 UUID generator, use it. if _uuid_generate_random: _buffer = ctypes.create_string_buffer(16) _uuid_generate_random(_buffer) return UUID(bytes=_buffer.raw) ... Changeset: r67318. The changeset was not related to this issue, but #4363 (Make uuid module functions usable without ctypes). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 12:53:18 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 09 Dec 2008 11:53:18 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1228816758.56.0.395743984917.issue1717@psf.upfronthosting.co.za> Message-ID: <493E5C29.6040007@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-09 10:59, Raymond Hettinger wrote: > Raymond Hettinger added the comment: > > Moving cmp() somewhere other than builtins is not progress. IMO, it > needs to die off and the concept of it needs to disappear completely. > Code is better without it. Three-way comparisons are PITA to use -- > their only virtue is as an optimization in the few cases where one > three-way test is cheaper to compute than two two-way tests. > > The goal for 3.0 was to have one way to do it and thereby simplify the > language. Tucking it away in a module or writing a new decorator > defeats the purpose. It simply should die and go away. The idea was to have one implementation of the work-around (a>b) - (b _______________________________________ From report at bugs.python.org Tue Dec 9 12:57:12 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2008 11:57:12 +0000 Subject: [issue4601] directory permission error with make install in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228823832.04.0.952444994471.issue4601@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The patch is fine. If it were me, I'd change os.walk to accept keyword-only arguments: def walk(top, *, topdown=True, onerror=None, followlinks=False): ... ---------- nosy: +amaury.forgeotdarc resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:13:43 2008 From: report at bugs.python.org (Jakub Wilk) Date: Tue, 09 Dec 2008 12:13:43 +0000 Subject: [issue4608] urllib.request.urlopen does not return an iterable object In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za> Message-ID: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za> New submission from Jakub Wilk : $ cat urltest2.5 #!/usr/bin/python2.5 from urllib2 import urlopen for line in urlopen('http://python.org/'): print line break $ ./urltest2.5 $ cat urltest3.0 #!/usr/bin/python3.0 from urllib.request import urlopen for line in urlopen('http://python.org/'): print(line) break $ ./urltest3.0 Traceback (most recent call last): File "./urltest3.0", line 3, in for line in urlopen('http://python.org/'): TypeError: 'addinfourl' object is not iterable ---------- components: Library (Lib) messages: 77405 nosy: jwilk, pl severity: normal status: open title: urllib.request.urlopen does not return an iterable object type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:19:38 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 12:19:38 +0000 Subject: [issue4601] directory permission error with make install in 3.0 In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za> Message-ID: <1228825178.82.0.627833485637.issue4601@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, there is not fixer for 2to3. But I might be hard to write such fixer because walk() generates (dirpath, dirnames, filenames) instead of (dirpath, filenames). Python2 prototype: os.path.walk(path, visit, arg) -> None with visit: callback(arg, dirpath, filenames) Python3 prototype: os.walk(top[, topdown=True[, onerror=None[, followlinks=False]]]) -> generator with onerror: callback() the generator produces (dirpath, dirnames, filenames) Example: os.path.walk('Lib/xml/', callback, 42) can be replaced by for dirpath, dirnames, filenames in os.walk('Lib/xml/'): callback(42, dirpath, dirnames + filenames) About the keyword only: +1 (or +2 :-)). Index: Lib/os.py =================================================================== --- Lib/os.py (r?vision 67652) +++ Lib/os.py (copie de travail) @@ -192,7 +192,7 @@ __all__.extend(["makedirs", "removedirs", "renames"]) -def walk(top, topdown=True, onerror=None, followlinks=False): +def walk(top, *, topdown=True, onerror=None, followlinks=False): """Directory tree generator. For each directory in the directory tree rooted at top (including top _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:28:27 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 12:28:27 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1228825707.83.0.348327212729.issue3439@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file11988/numbits-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:28:30 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 12:28:30 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1228825710.51.0.00673607294557.issue3439@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file11990/numbits-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:28:55 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 12:28:55 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1228825735.54.0.152404349536.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: New version of my patch using a method instead of a property. Added file: http://bugs.python.org/file12302/numbits-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:29:17 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2008 12:29:17 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228825757.83.0.792789457726.issue4580@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Please, can you provide a patch that does not change whitespace everywhere? Even if these files use indentation inconsistently; the patch will be smaller and much easier to proofread. (I vaguely remember a document saying that it's better to separate whitespace change from real development, but I cannot find it.) ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:50:59 2008 From: report at bugs.python.org (Senthil) Date: Tue, 09 Dec 2008 12:50:59 +0000 Subject: [issue4608] urllib.request.urlopen does not return an iterable object In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za> Message-ID: <1228827059.62.0.603971880259.issue4608@psf.upfronthosting.co.za> Senthil added the comment: I verified this bug in the Py3.0 and Py3.1. Shall come out with a patch for it. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:51:06 2008 From: report at bugs.python.org (Peter Saunders) Date: Tue, 09 Dec 2008 12:51:06 +0000 Subject: [issue4609] Allow use of > 256 FD's on solaris in 32 bit mode In-Reply-To: <1228827066.41.0.986801678261.issue4609@psf.upfronthosting.co.za> Message-ID: <1228827066.41.0.986801678261.issue4609@psf.upfronthosting.co.za> New submission from Peter Saunders : Feature Request: Could configure etc be modified to detect if it can use enable_extended_FILE_stdio() to allow solaris to use > 256 FD's while still be compiled 32 bit. This is a new feature in Solaris 10 (came in Update 4). Some futher infomation on this: http://developers.sun.com/solaris/articles/stdio_256.html (Scroll to "Programming Solutions") http://docs.sun.com/app/docs/doc/819-2243/enable-extended-file-stdio-3c?a=view ---------- components: Interpreter Core messages: 77410 nosy: pajs at fodder.org.uk severity: normal status: open title: Allow use of > 256 FD's on solaris in 32 bit mode versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:51:13 2008 From: report at bugs.python.org (Peter Saunders) Date: Tue, 09 Dec 2008 12:51:13 +0000 Subject: [issue4609] Allow use of > 256 FD's on solaris in 32 bit mode In-Reply-To: <1228827066.41.0.986801678261.issue4609@psf.upfronthosting.co.za> Message-ID: <1228827073.96.0.185529633007.issue4609@psf.upfronthosting.co.za> Changes by Peter Saunders : ---------- components: +Distutils -Interpreter Core type: -> feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:51:36 2008 From: report at bugs.python.org (Peter Saunders) Date: Tue, 09 Dec 2008 12:51:36 +0000 Subject: [issue4609] Allow use of > 256 FD's on solaris in 32 bit mode In-Reply-To: <1228827066.41.0.986801678261.issue4609@psf.upfronthosting.co.za> Message-ID: <1228827096.12.0.344024609767.issue4609@psf.upfronthosting.co.za> Changes by Peter Saunders : ---------- components: +Interpreter Core -Distutils _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 14:13:04 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 13:13:04 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228828384.56.0.813562194316.issue3166@psf.upfronthosting.co.za> STINNER Victor added the comment: float(295147905179352891391L) gives different result on Python 2.5 and Python 2.6: - 2.9514790517935289e+20 # Python 2.5.1 - 2.9514790517935283e+20 # 2.7a0 whereas the code is the same!? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 14:33:41 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 13:33:41 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228829621.62.0.773870975195.issue3166@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>> reduce(lambda x,y: x*32768.0 + y, [256, 0, 0, 1, 32767]) 2.9514790517935283e+20 >>> float(295147905179352891391L) 2.9514790517935289e+20 Python 2.7a0 (trunk:67679M, Dec 9 2008, 14:29:12) >>> reduce(lambda x,y: x*32768.0 + y, [256, 0, 0, 1, 32767]) 2.9514790517935283e+20 >>> float(295147905179352891391L) 2.9514790517935283e+20 Python 3.1a0 (py3k:67652M, Dec 9 2008, 13:08:19) >>> float(295147905179352891391) 2.9514790517935283e+20 >>> digits=[256, 0, 0, 1, 32767]; x=0 >>> for d in digits: ... x*=32768.0 ... x+= d ... >>> x 2.9514790517935283e+20 All results are the same, except float(295147905179352891391L) in Python 2.5!? Python 2.5 rounds correctly: Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>> x=295147905179352891391L >>> long(float(long(x))) - x 1L _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 14:37:51 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 09 Dec 2008 13:37:51 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228829871.76.0.998376573548.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: Copy & paste from python-dev post: The problem with memoryview appears to be related to the way it calculates its own length (since that is the check that is failing when the view blows up): >>> a = array('i', range(10)) >>> m = memoryview(a) >>> len(m) # This is the length in bytes, which is WRONG! 40 >>> m2 = memoryview(a)[2:8] >>> len(m2) # This is correct 6 >>> a2 = array('i', range(6)) >>> m[:] = a # But this works >>> m2[:] = a2 # and this does not Traceback (most recent call last): File "", line 1, in ValueError: cannot modify size of memoryview object >>> len(memoryview(a2)) # Ah, 24 != 6 is our problem! 24 Looks to me like there are a couple of bugs here: The first is that memoryview is treating the len field in the Py_buffer struct as the number of objects in the view in a few places instead of as the total number of bytes being exposed (it is actually the latter, as defined in PEP 3118). The second is that the getbuf implementation in array.array is broken. It is ONLY OK for shape to be null when ndim=0 (i.e. a scalar value). An array is NOT a scalar value, so the array objects should be setting the shape pointer to point to an single item array (where shape[0] is the length of the array). memoryview can then be fixed to use shape[0] instead of len to get the number of objects in the view. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 14:46:35 2008 From: report at bugs.python.org (John Stracke) Date: Tue, 09 Dec 2008 13:46:35 +0000 Subject: [issue4594] Can't compile with -O3, on ARM, with gcc 3.4.4 In-Reply-To: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za> Message-ID: <1228830395.68.0.500415784702.issue4594@psf.upfronthosting.co.za> John Stracke added the comment: The OPT env var is good. Maybe it could be documented in configure --help? And, yeah, recognizing the platform is messy. I'll dig and see whether gcc3 does the same thing on x86, though; if so, some logic to say "use -O2 for gcc <4" shouldn't be so bad. _______________________________________ Python tracker _______________________________________ From jeremy at alum.mit.edu Tue Dec 9 14:48:14 2008 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Tue, 9 Dec 2008 08:48:14 -0500 Subject: [issue4608] urllib.request.urlopen does not return an iterable object In-Reply-To: <1228827059.62.0.603971880259.issue4608@psf.upfronthosting.co.za> References: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za> <1228827059.62.0.603971880259.issue4608@psf.upfronthosting.co.za> Message-ID: Oops. I didn't think it translate the code in addinfobase to the new style of iterators. Jeremy On Tue, Dec 9, 2008 at 7:50 AM, Senthil wrote: > > Senthil added the comment: > > I verified this bug in the Py3.0 and Py3.1. Shall come out with a patch > for it. > > ---------- > nosy: +orsenthil > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > From report at bugs.python.org Tue Dec 9 14:48:17 2008 From: report at bugs.python.org (Jeremy Hylton) Date: Tue, 09 Dec 2008 13:48:17 +0000 Subject: [issue4608] urllib.request.urlopen does not return an iterable object In-Reply-To: <1228827059.62.0.603971880259.issue4608@psf.upfronthosting.co.za> Message-ID: Jeremy Hylton added the comment: Oops. I didn't think it translate the code in addinfobase to the new style of iterators. Jeremy On Tue, Dec 9, 2008 at 7:50 AM, Senthil wrote: > > Senthil added the comment: > > I verified this bug in the Py3.0 and Py3.1. Shall come out with a patch > for it. > > ---------- > nosy: +orsenthil > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ---------- nosy: +jhylton _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 14:58:02 2008 From: report at bugs.python.org (John Stracke) Date: Tue, 09 Dec 2008 13:58:02 +0000 Subject: [issue4594] Can't compile with -O3, on ARM, with gcc 3.4.4 In-Reply-To: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za> Message-ID: <1228831082.17.0.211123780586.issue4594@psf.upfronthosting.co.za> John Stracke added the comment: OK, nope, gcc 3.4.6 on x86-64 builds fine. So, please, just have configure --help mention OPT. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:50:30 2008 From: report at bugs.python.org (Alex Stapleton) Date: Tue, 09 Dec 2008 14:50:30 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za> Message-ID: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za> New submission from Alex Stapleton : Following a discussion on reddit it seems that the unicode case conversion algorithms are not being followed. $ python3.0 Python 3.0rc1 (r30rc1:66499, Oct 10 2008, 02:33:36) [GCC 4.0.1 (Apple Inc. build 5488)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> x='?' >>> print(x, x.upper()) ? ? This conversion is correct as defined in UnicodeData.txt however http://unicode.org/Public/UNIDATA/SpecialCasing.txt defines a more complete set of case conversions. According to this file "?".upper() should be "SS". Presumably Python simply isn't using this file to create it's mapping database. ---------- components: Unicode messages: 77417 nosy: alexs severity: normal status: open title: Unicode case mappings are incorrect type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:56:59 2008 From: report at bugs.python.org (David W. Lambert) Date: Tue, 09 Dec 2008 14:56:59 +0000 Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za> Message-ID: <1228834619.41.0.368908070234.issue4606@psf.upfronthosting.co.za> Changes by David W. Lambert : ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:59:59 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 14:59:59 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228834799.19.0.954122480352.issue3166@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I understand why different versions of the same code gives different results: compiler flags! Python 2.5.1 is my Ubuntu version (should be compiled with -O3) whereas Python 2.7 and 3.1a0 are compiled by me with -00. Results with Python 2.5.1: - with -O0, float(295147905179352891391L) gives 2.9514790517935283e+20 - with -O1, float(295147905179352891391L) gives 2.9514790517935289e+20 I'm unable to isolate the exact compiler flag which changes the result. I tried all options listed in the gcc doc for the -O1 option: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:03:28 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Dec 2008 15:03:28 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228835008.19.0.930371446226.issue4580@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sorry for the whitespace changes, here is a patch that has less of them... hope that helps ;-S Added file: http://bugs.python.org/file12303/issue4580ws.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:06:55 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Dec 2008 15:06:55 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228835215.68.0.307817759742.issue1717@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The idea was to have one implementation of the work-around (a>b) - (b instead of 10 or so instances of this snippet in the Python stdlib > and probably a few hundred places in other code. But what use-case does it solve, except for making legacy code easier to port to Py3k? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:09:57 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 15:09:57 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228835397.03.0.793745610757.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: Victor, what does >>> 1e16 + 2.9999 give on your Ubuntu 2.5 machine? (Humor me. :) ) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:10:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 09 Dec 2008 15:10:20 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228835420.86.0.425036029302.issue4335@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Just to add to the list of getsource quirks: with the following in x.py, f = lambda: 0 \ [EOF] >>> import inspect, x; inspect.getsource(x.f) Traceback (most recent call last): .. tokenize.TokenError: ('EOF in multi-line statement', (2, 0)) Same with def f(): 0 \ [EOF] _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:13:45 2008 From: report at bugs.python.org (Elizabeth Chang) Date: Tue, 09 Dec 2008 15:13:45 +0000 Subject: [issue4598] IDLE not opening In-Reply-To: <1228777419.15.0.4177651652.issue4598@psf.upfronthosting.co.za> Message-ID: <07B7870CE4945841951B429C10A4C929900A96@email1.mitretek.org> Elizabeth Chang added the comment: No, I don't have those set. - Elizabeth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:20:54 2008 From: report at bugs.python.org (Thomas Lee) Date: Tue, 09 Dec 2008 15:20:54 +0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1228836054.8.0.998348342084.issue1615@psf.upfronthosting.co.za> Thomas Lee added the comment: Related reading from a few years back: http://coding.derkeiler.com/Archive/Python/comp.lang.python/2005-05/msg03829.html ---------- nosy: +thomas.lee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:35:51 2008 From: report at bugs.python.org (=?utf-8?q?Kuba_Ko=C5=84czyk?=) Date: Tue, 09 Dec 2008 15:35:51 +0000 Subject: [issue4611] Small error in "Extending Python with C or C++" In-Reply-To: <1228836951.42.0.539810823139.issue4611@psf.upfronthosting.co.za> Message-ID: <1228836951.42.0.539810823139.issue4611@psf.upfronthosting.co.za> New submission from Kuba Ko?czyk : Near the end of "Reference Counting in Python" section we have: "(...)The disadvantage of borrowing over leaking is(...)", "leaking" should be replaced by "borrowing". ---------- assignee: georg.brandl components: Documentation messages: 77425 nosy: georg.brandl, jakamkon severity: normal status: open title: Small error in "Extending Python with C or C++" versions: Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:37:16 2008 From: report at bugs.python.org (=?utf-8?q?Kuba_Ko=C5=84czyk?=) Date: Tue, 09 Dec 2008 15:37:16 +0000 Subject: [issue4611] Small error in "Extending Python with C or C++" In-Reply-To: <1228836951.42.0.539810823139.issue4611@psf.upfronthosting.co.za> Message-ID: <1228837036.63.0.437258120373.issue4611@psf.upfronthosting.co.za> Kuba Ko?czyk added the comment: I meant "owning". _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:38:02 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 15:38:02 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228837082.27.0.262143506628.issue3166@psf.upfronthosting.co.za> STINNER Victor added the comment: About -O0 vs -O1, I think that I understood (by reading the assembler). pseudocode of the -O0 version: while (....) { load x from the stack x = x * ... + ... write x to the stack } pseudocode of the -O1 version: while (....) { x = x * ... + ... } Intel uses 80 bits float in internals, but load/store uses 64 bits float. Load/store looses least significant bits. Hey, floating point numbers are funny :-) --- Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>> 1e16 + 2.999 10000000000000002.0 >>> 1e16 + 2.9999 10000000000000004.0 Same result with python 2.7/3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:41:10 2008 From: report at bugs.python.org (blake madden) Date: Tue, 09 Dec 2008 15:41:10 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> Message-ID: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> New submission from blake madden : In reference to Issue4592 (which includes a patch), PyModule_Create()calls PyModule_New instead of PyImport_AddModule. Because of this, calling PyModule_Create() won't work like Py_InitModule(). Is this correct, because the documentation is showing that PyModule_Create() is all you need to use to create and add a module to the system. However, this is not the case. ---------- components: Extension Modules messages: 77428 nosy: blakemadden severity: normal status: open title: PyModule_Create() doesn't add/import module type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:52:57 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2008 15:52:57 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228837977.69.0.627831290748.issue3166@psf.upfronthosting.co.za> STINNER Victor added the comment: An interresting document: "Request for Comments: Rounding in PHP" http://wiki.php.net/rfc/rounding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:02:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 16:02:27 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228838547.04.0.718582401372.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Intel uses 80 bits float in internals, but load/store uses 64 bits > float. Load/store looses least significant bits. Exactly. If your Intel machine is Pentium 4 or newer, you can get around this by using the SSE2 extensions, which work with 64-bit doubles throughout. I don't remember offhand precisely which gcc flags you need for this. > Hey, floating point numbers are funny :-) Yup. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:12:04 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 09 Dec 2008 16:12:04 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1228838547.04.0.718582401372.issue3166@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Tue, Dec 9, 2008 at 11:02 AM, Mark Dickinson wrote: ... > If your Intel machine is Pentium 4 or newer, you can get > around this by using the SSE2 extensions, which work with 64-bit doubles > throughout. I don't remember offhand precisely which gcc flags you need > for this. The flags you may be looking for are -msse2 -mfpmath=sse _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:43:25 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 16:43:25 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228841005.45.0.0654646748459.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Alexander] > The flags you may be looking for are -msse2 -mfpmath=sse Thanks, Alexander! [Alexander again, from an earlier post...] > I noticed that you replaced a call to _PyLong_AsScaledDouble with your > round to nearest algorithm. I wonder if _PyLong_AsScaledDouble itself > would benefit from your change. Currently it is used in PyLong_AsDouble > and long_true_divide. I would think that long_true_divide would be more > accurate if longs were rounded to the nearest float. You read my mind! I've got another issue open about making long division round correctly, somewhere. And indeed I'd like to make _PyLong_AsScaledDouble do correct rounding. (I'd also like to make it return the exponent in bits, rather than digits, so that mathmodule.c doesn't have to know about the long int representation, but that's another story...) > I believe _PyLong_AsScaledDouble is written the way it is to support > non-IEEE floating formats, but I am not sure that your algorithm would > always return the nearest float on an arbitrary non-IEEE platform. Well, I had other possible formats in mind when I wrote the code, and I hope it's good whenever FLT_RADIX is 2. If you can think of explicit cases where it's not going to work, please let me know. My belief that it's safe rests on two facts: (1) it entirely avoids IEEE 754 oddities like negative zero, denormals and NaNs, and (2) all the floating-point operations actually performed should have exact results, so rounding doesn't come into play anywhere. When FLT_RADIX is some other power of 2 (FLT_RADIX=16 is the only example I know of that exists in the wild) the code probably doesn't produce correctly rounded results in all cases, but it shouldn't do anything catastrophic either---I think the error still should't be more than 1ulp in this case. When FLT_RADIX is not a power of 2 then so much else is going to be broken anyway that it's not worth worrying about. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:43:41 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 09 Dec 2008 16:43:41 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228841021.74.0.940350841847.issue4335@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: You convinced me. After all, if python interpreter does not complain about missing end-of-line and processes the unterminated line, getsource should report it. Here is a patch that passes existing tests and adds a "NoEOF" test case. I am adding 2.5.3 to the list of versions, but someone will have to lobby python-dev to make it happen. Note that I've modernized the code a little bit by switching from a callback tokenizer to the newer token generator. Hopefully this will make it easier to review the code, but I can easily produce an old-style patch as well. ---------- versions: +Python 2.5.3, Python 2.6, Python 2.7 -Python 2.5 Added file: http://bugs.python.org/file12304/issue4335.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:45:28 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 09 Dec 2008 16:45:28 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1228835215.68.0.307817759742.issue1717@psf.upfronthosting.co.za> Message-ID: <493EA0A5.4060101@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-09 16:06, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> The idea was to have one implementation of the work-around (a>b) - (b> instead of 10 or so instances of this snippet in the Python stdlib >> and probably a few hundred places in other code. > > But what use-case does it solve, except for making legacy code easier to > port to Py3k? It implements the DRY principle. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:51:56 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 16:51:56 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228841516.64.0.92765264089.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Alexander] > I also wonder whether round to nearest float can be implemented without > floating point arithmetics. I would think round towards zero should be > a simple matter of extracting an appropriate number of bits from the > long and round to nearest would at most require a long addition. The idea's attractive. The problem is finding an integer type that's guaranteed to have enough bits to store the mantissa for the float (probably plus one or two bits more for comfort); for IEEE 754 this means a 64-bit integer type, and there aren't any of those in C89. (One could use two 32-bit integer variables, but that's going to get messy.) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:31:24 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 09 Dec 2008 17:31:24 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1228841516.64.0.92765264089.issue3166@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: .. > The idea's attractive. The problem is finding an integer type that's > guaranteed to have enough bits to store the mantissa for the float > (probably plus one or two bits more for comfort); for IEEE 754 this > means a 64-bit integer type, and there aren't any of those in C89. But Python already has an arbitrary precision integer type, why not use it? Performance may suffer, but optimization can be considered later possibly first on the most popular platforms. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:38:14 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Tue, 09 Dec 2008 17:38:14 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228844294.96.0.943259001656.issue3166@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:39:13 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 17:39:13 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228844353.57.0.159833449923.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: As you say, performance would suffer. What would using Python's integer type solve, that isn't already solved by the patch? I know the code isn't terribly readable; I'll add some comments explaining clearly what's going on. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:47:40 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Tue, 09 Dec 2008 17:47:40 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1228844860.81.0.870931194121.issue4566@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 19:27:19 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 09 Dec 2008 18:27:19 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1228844353.57.0.159833449923.issue3166@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Tue, Dec 9, 2008 at 12:39 PM, Mark Dickinson wrote: .. > What would using Python's integer type solve, that isn't already solved by > the patch? > Speaking for myself, it would alleviate the irrational fear of anything involving the FPU. :-) Seriously, it is not obvious that your algorithm is correct and does not depend on x being stored in an extended precision register. Floating point experts are in short supply, so it may take a while for your patch to be thoroughly reviewed by one of them. If you could produce a formal proof of correctness of your algorithm, that would be more helpful than code comments. On the other hand, an implementation that uses only integer arithmetics plus bit shifts is likely to be much easier to understand. I don't think the performance will suffer much. We can even start with a pure python prototype using struct.pack or ctypes to produce the double result. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 19:35:06 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 18:35:06 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> Message-ID: <1228847706.28.0.409173080636.issue4612@psf.upfronthosting.co.za> Brett Cannon added the comment: Are you returning the module in your extension's init function? The import machinery takes the returned module from the init function and adds it to sys.modules for you. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 19:35:32 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 18:35:32 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> Message-ID: <1228847732.14.0.0223135465052.issue4612@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 19:45:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Dec 2008 18:45:40 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228848340.48.0.780205914081.issue4604@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, it seems to happen if you first call read() before calling close(). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 20:18:31 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 19:18:31 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228850311.4.0.978737318628.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: By the way, the algorithm here is essentially the same as the algorithm that I implemented for the float.fromhex method, except that the float.fromhex method is more complicated in that it may have to deal with signed zeros or subnormals. So any mathematical defects that you find in this patch probably indicate a defect in float.fromhex too. In fact, the code *does* do integer arithmetic, except that one of the integers happens to be stored as a double. If you look at the code you'll find that at every stage, the floating-point variable "x" has an exact nonnegative integer value between 0 and 2**DBL_MANT_DIG. All such values are exactly representable as a double, and all the arithmetic operations involved are exact. This holds right up to the ldexp call at the end. So the arithmetic with x is essentially integer arithmetic. I accept the code needs extra documentation; I was planning to put the equivalent Python code into the comments to make things clearer. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 20:35:59 2008 From: report at bugs.python.org (blake madden) Date: Tue, 09 Dec 2008 19:35:59 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> Message-ID: <1228851359.77.0.50999586866.issue4612@psf.upfronthosting.co.za> blake madden added the comment: Sorry, mate, that's all Greek to me--I'm a total noob with Python. I'm simply trying to run the example in r67655 (the "Extending Embedded Python" example) and it fails with "'emb' not being found". It appears that calling "PyModule_Create(&EmbModule);" is not enough to create and import the library. Somebody made a comment in Issue4592 that "PyModule_Create" was missing some logic, so I'm reporting that here. I honestly don't know if there is something wrong with "PyModule_Create" or if the example is missing something. I'm just trying to get this example to work. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 20:36:06 2008 From: report at bugs.python.org (Albert Hopkins) Date: Tue, 09 Dec 2008 19:36:06 +0000 Subject: [issue4613] Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za> Message-ID: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za> New submission from Albert Hopkins : Say I have module foo.py: def a(x): def b(): x del x If I run foo.py under Python 2.4.4 I get: File "foo.py", line 4 del x SyntaxError: can not delete variable 'x' referenced in nested scope Under Python 2.6 and Python 3.0 I get: SyntaxError: can not delete variable 'x' referenced in nested scope The difference is under Python 2.4 I get a traceback with the lineno and offending line, but I do not get a traceback in Pythons 2.6 and 3.0. This also kinda relates to the 2to3 tool. See: http://groups.google.com/group/comp.lang.python/browse_frm/thread/a6600c80f8c3c60c/4d804532ea09aae7 ---------- components: Interpreter Core messages: 77443 nosy: marduk severity: normal status: open title: Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 21:26:46 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2008 20:26:46 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228854406.77.0.0336798172777.issue1717@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido approved removing __builtin__.cmp() in 3.0.1. It was supposed to have been taken out but was forgotten. With respect to the DRY principle, I disagree about its utility here. The code is so simple that it doesn't warrant cross-module factorization. It is a better goal to minimize dependencies. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 21:53:11 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 20:53:11 +0000 Subject: [issue4592] Example patch is missing something In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228855991.64.0.91897006882.issue4592@psf.upfronthosting.co.za> Brett Cannon added the comment: Because the init function for extension modules are supposed to return the module now and the import machinery adds the module itself. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 21:55:05 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 20:55:05 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228856105.81.0.721088380088.issue4604@psf.upfronthosting.co.za> Skip Montanaro added the comment: Here's a test case (diff against Lib/test/test_io.py). This fails for me on OS X 10.5.5 with the tip of the py3k branch. ---------- keywords: +patch Added file: http://bugs.python.org/file12305/iobug.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 21:55:13 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 20:55:13 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228856113.92.0.028182330049.issue4604@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 21:56:21 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 20:56:21 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> Message-ID: <1228856181.3.0.361494749268.issue4612@psf.upfronthosting.co.za> Brett Cannon added the comment: Ah, I had not looked at the issue; sorry about the confusion. PyImport_Create() is doing what it is supposed to be doing and should not call PyImport_AddModule(). The example is wrong. Closing this as invalid since the example is off. ---------- resolution: -> invalid status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 21:59:38 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 20:59:38 +0000 Subject: [issue4586] "Extending Embedded Python" documention uses removed Py_InitModule function In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> Message-ID: <1228856378.31.0.816185355702.issue4586@psf.upfronthosting.co.za> Brett Cannon added the comment: You are probably looking at http://docs.python.org/3.0/ still and that only updates when a new release happens. To see the in-development docs look at http://docs.python.org/dev/3.0/ . And the problem with the docs and its new PyModule_Create() usage is being worked on in Issue4592 (already have a history over there so not reopening this one). ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:00:26 2008 From: report at bugs.python.org (blake madden) Date: Tue, 09 Dec 2008 21:00:26 +0000 Subject: [issue4592] Example patch is missing something In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228856426.68.0.926980188744.issue4592@psf.upfronthosting.co.za> blake madden added the comment: So, does that mean that Python is fine and there is a problem in the example? How do I get that example to work, there seems to be something missing in it. Thanks. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:00:32 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 21:00:32 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228856432.8.0.635401691999.issue4604@psf.upfronthosting.co.za> Skip Montanaro added the comment: fixed patch. I'm still a bit clumsy with the assertRaises stuff. Added file: http://bugs.python.org/file12306/iobug.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:02:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 21:02:37 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228856557.61.0.544208850404.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: > floating-point variable "x" has an exact nonnegative integer value > between 0 and 2**DBL_MANT_DIG. Hmm. On closer inspection that's not quite true. After the line x = x * PyLong_BASE + (dig & (PyLong_BASE - pmask)); x has a value of the form n * pmask, where pmask is a power of 2 and n is in the range [0, 2**DBL_MANT_DIG). It's still exactly represented, provided that FLT_RADIX is 2. (It's the multiplications by powers of 2 that get hairy when FLT_RADIX is 16, since they *can* lose information.) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:03:46 2008 From: report at bugs.python.org (Jean Brouwers) Date: Tue, 09 Dec 2008 21:03:46 +0000 Subject: [issue3167] math test fails on Solaris 10 In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za> Message-ID: <1228856626.08.0.322031140176.issue3167@psf.upfronthosting.co.za> Jean Brouwers added the comment: It looks like the patch did fix the problems. Attached are the results for 32- and 64-bit Python 2.6.1 with and without the patch, all built with SUN's compilers on Solaris 10 (Opteron). The math log tests failed with the 32-bit build before and passed after applying the patch. The 64-bit build passed before and still passes after the patch. Added file: http://bugs.python.org/file12307/Python-2.6.1-32bit-Solaris10-math_patch.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:04:10 2008 From: report at bugs.python.org (Jean Brouwers) Date: Tue, 09 Dec 2008 21:04:10 +0000 Subject: [issue3167] math test fails on Solaris 10 In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za> Message-ID: <1228856650.36.0.574178928089.issue3167@psf.upfronthosting.co.za> Changes by Jean Brouwers : Added file: http://bugs.python.org/file12308/Python-2.6.1-64bit-Solaris10-math_patch.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:05:25 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 21:05:25 +0000 Subject: [issue4592] Embedding example does not add created module In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228856725.39.0.419085426354.issue4592@psf.upfronthosting.co.za> Brett Cannon added the comment: The example is broken. And the example under discussion is http://docs.python.org/dev/3.0/extending/embedding.html#extending-embedded-python . I have changed the title to be more descriptive and assigned to Martin to find out what the proper way is to handle this case. ---------- assignee: georg.brandl -> loewis priority: -> critical stage: -> needs patch title: Example patch is missing something -> Embedding example does not add created module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:06:47 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 21:06:47 +0000 Subject: [issue4614] Document PyModule_Create() In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za> Message-ID: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za> New submission from Brett Cannon : PyModule_Create() is not documented (or at least it isn't showing up in the C API index). Might be other parts of the new module initialization API that are not documented either. ---------- assignee: georg.brandl components: Documentation messages: 77454 nosy: brett.cannon, georg.brandl severity: normal stage: needs patch status: open title: Document PyModule_Create() type: behavior versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:10:17 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 21:10:17 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228857017.1.0.284666199352.issue4604@psf.upfronthosting.co.za> Skip Montanaro added the comment: Here's a minimal patch to BufferedReader.read() which causes the test to pass. I will leave it for smarter people to decided whether or not all the other read() methods need the same test. Added file: http://bugs.python.org/file12309/io.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:10:22 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 21:10:22 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228857022.95.0.781917991056.issue4604@psf.upfronthosting.co.za> Changes by Skip Montanaro : Removed file: http://bugs.python.org/file12305/iobug.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:12:36 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 09 Dec 2008 21:12:36 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228857156.04.0.779219437567.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: The patch still gets the length of memory view objects wrong - it just makes it *consistently* wrong so that the specific assignment being tested appears to work. Note the following behaviour with the current memoryview : >>> from array import array >>> a10 = array('i', range(10)) >>> a6 = array('i', range(6)) >>> m10 = memoryview(a10) >>> m6 = memoryview(a6) >>> m = m10[2:8] >>> len(m10) 40 >>> len(m6) 24 >>> len(m) 6 The patch will change the last item to 24 which will make the assignment work, but it's still not the right answer! As it turns out though, in addition to the length problems, this is far from the only problem with memory view assignment - the damn things are so finicky, it's practically impossible to assign anything to them: >>> a = array('i', range(10)) >>> m = memoryview(a) >>> m[1] = 1 # An integer perhaps? Traceback (most recent call last): File "", line 1, in TypeError: 'int' does not have the buffer interface >>> m[1] = array('i', range(1)) # A single valued array? Traceback (most recent call last): File "", line 1, in ValueError: cannot modify size of memoryview object >>> m[1] = b"1234" # A bytes object of the correct size? Traceback (most recent call last): File "", line 1, in TypeError: mismatching item sizes for "array.array" and "bytes" >>> m[:1] = [0] # How about a sequence? Traceback (most recent call last): File "", line 1, in TypeError: 'list' does not have the buffer interface >>> m[1] = memoryview(array('i', range(1)))[:1] # Force the returned 'len' to be wrong (but right for what memoryview is going to do with it) and the assignment works I guess fixing most of those qualify as enhancements though, as opposed to the length calculation which is simply an outright bug. So... 1. memoryview needs to be fixed so that internally self->view.len is always the length in bytes, even after taking a slice of the view 2. memoryview needs to be fixed so that len() reflects the number of items in the view (i.e. self->view.shape[0]), not the total number of bytes 3. array.array needs to be fixed so that it populates the shape array (a pointer to the arrays own internal length field should be adequate) 4. PyObject_GetBuffer needs to raise an exception if it sees ndim > 0 with a NULL shape array in the resulting Py_buffer. The only time shape=NULL is allowed is when ndim=0 (i.e. scalar values) because at that point the length of the shape array is 0. The /* XXX */ comment in the memoryview code about shape not being required by PEP 3118 needs to go away because it *is* required - array.array is just broken in not providing it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:12:36 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 21:12:36 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228857156.21.0.658997099847.issue4604@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:50:58 2008 From: report at bugs.python.org (blake madden) Date: Tue, 09 Dec 2008 21:50:58 +0000 Subject: [issue4586] "Extending Embedded Python" documention uses removed Py_InitModule function In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> Message-ID: <1228859458.95.0.996485127417.issue4586@psf.upfronthosting.co.za> blake madden added the comment: "You are probably looking at http://docs.python.org/3.0/ still and that only updates when a new release happens." Didn't you just have a new release, Python 3? I thought the website said it was a stable release? The production help for Python 3 is using Py_InitModule, which doesn't even exist in the production release of Python 3. I stopped looking at that help when I figured that out, and after that I have been looking at the DEV help which (as you mentioned) does not work for other reasons. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:08:28 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 09 Dec 2008 22:08:28 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228813190.52.0.916898681593.issue4589@psf.upfronthosting.co.za> Message-ID: <493EEC59.1030603@v.loewis.de> Martin v. L?wis added the comment: > Does it need to be backported to 2.5? IMO it is a corner case. Not necessarily. If nobody volunteers, it won't be backported, which is fine with me. The only potential release blocker for a bug fix release can be a regression, which this isn't. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:08:56 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 09 Dec 2008 22:08:56 +0000 Subject: [issue4586] "Extending Embedded Python" documention uses removed Py_InitModule function In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za> Message-ID: <1228860536.88.0.622840769993.issue4586@psf.upfronthosting.co.za> Georg Brandl added the comment: Brett: > You are probably looking at http://docs.python.org/3.0/ still and that > only updates when a new release happens. That is not true, I want it to update continually, like the 2.6 ones, and have already contacted Neal about it. Blake: > Didn't you just have a new release, Python 3? I thought the website > said it was a stable release? The production help for Python 3 is using > Py_InitModule, which doesn't even exist in the production release of > Python 3. Yes. The production help is not without errors, since many changes to the Python 3 branch haven't been properly documented. But as said, when all is set up correctly, the docs.python.org/3.0 docs will update and correct errors such as this one. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:10:35 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 09 Dec 2008 22:10:35 +0000 Subject: [issue4594] Can't compile with -O3, on ARM, with gcc 3.4.4 In-Reply-To: <1228831082.17.0.211123780586.issue4594@psf.upfronthosting.co.za> Message-ID: <493EECD9.7070702@v.loewis.de> Martin v. L?wis added the comment: > OK, nope, gcc 3.4.6 on x86-64 builds fine. So, please, just have > configure --help mention OPT. Can you contribute a patch? I'm skeptical it whether it is even possible to influence the output of --help. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:14:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 09 Dec 2008 22:14:45 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za> Message-ID: <1228860885.35.0.831968469276.issue4610@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have known this problem for years, and decided not to act; I don't consider it an important problem. Implementing it properly is complicated by the fact that some of the case mappings are conditional on the locale. If you consider it important, please submit a patch. I'd rather see efforts put into an integration of ICU, which should solve this problem and many others with Python's locale support. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:15:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 09 Dec 2008 22:15:49 +0000 Subject: [issue4598] IDLE not opening In-Reply-To: <1228767721.74.0.672735673887.issue4598@psf.upfronthosting.co.za> Message-ID: <1228860949.85.0.139875505378.issue4598@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, then please run, in a cmd.exe shell, in the Python directory python.exe Lib\idlelib\idle.py and report its output. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:17:36 2008 From: report at bugs.python.org (Roumen Petrov) Date: Tue, 09 Dec 2008 22:17:36 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <1228861056.05.0.252738034354.issue4587@psf.upfronthosting.co.za> Roumen Petrov added the comment: ok for patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:22:41 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 09 Dec 2008 22:22:41 +0000 Subject: [issue4592] Embedding example does not add created module In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228861361.77.0.972590778695.issue4592@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The proper way of extending embedded Python can be seen in Demo/embed/demo.c. I can't contribute to the documentation, so I'm unassigning myself. ---------- assignee: loewis -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:34:19 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2008 22:34:19 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> Message-ID: <1228862059.71.0.531690540242.issue4612@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: When python is embedded in a program, there must be a way for the program to export some of its functions to python - a module that resides in the main executable. You cannot use the import machinery to import such a module, because there is no separate file to find and load. Instead, the embedding program explicitly calls the module init() function. With python 2.x, this creates the module *and* inserts it into sys.modules. Then subsequent imports will find it directly in sys.modules. mod_python for example works this way. I maintain that the sample is still valid, and should be made to work somehow. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:35:50 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 09 Dec 2008 22:35:50 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1228862150.73.0.656200850067.issue1180@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Unfortunately, it missed the deadlines (i.e. nobody checked it in in time). I'll look into it. ---------- assignee: -> loewis priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:36:33 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2008 22:36:33 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228862059.71.0.531690540242.issue4612@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Tue, Dec 9, 2008 at 14:34, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > When python is embedded in a program, there must be a way for the > program to export > some of its functions to python - a module that resides in the main > executable. > > You cannot use the import machinery to import such a module, because > there is no > separate file to find and load. Instead, the embedding program > explicitly calls the > module init() function. > With python 2.x, this creates the module *and* inserts it into > sys.modules. Then > subsequent imports will find it directly in sys.modules. > > mod_python for example works this way. > I maintain that the sample is still valid, and should be made to work > somehow. That's what I mean; the example is off as in incorrect. Not off as in trying to do something silly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:44:16 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2008 22:44:16 +0000 Subject: [issue4612] PyModule_Create() doesn't add/import module In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za> Message-ID: <1228862656.27.0.761033612566.issue4612@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: OK. I'm currently writing a documentation patch for issue4592. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:03:07 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Dec 2008 23:03:07 +0000 Subject: [issue4587] Need to rework the dbm lib/include selection process In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local> Message-ID: <1228863787.51.0.713915743319.issue4587@psf.upfronthosting.co.za> Skip Montanaro added the comment: Thanks Roumen. Can I get a verdict on this approach from one of the main Python developers? I'm thinking a better way to control this would be to add a --flag to the build command to control the search order. ---------- assignee: -> skip.montanaro keywords: +needs review stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:21:17 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Dec 2008 23:21:17 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228857156.04.0.779219437567.issue4580@psf.upfronthosting.co.za> Message-ID: <1228864873.25750.4.camel@localhost> Antoine Pitrou added the comment: Hi Nick, > 1. memoryview needs to be fixed so that internally self->view.len is > always the length in bytes, even after taking a slice of the view This is in my patch, unless I'm missing something? > 2. memoryview needs to be fixed so that len() reflects the number of > items in the view (i.e. self->view.shape[0]), not the total number of bytes Why should that be? There's nothing suggesting that in the PEP. On the other hand I agree it looks a bit higher-level. > 3. array.array needs to be fixed so that it populates the shape array (a > pointer to the arrays own internal length field should be adequate) array.array is broken but that's a separate issue IMO (see e.g. #4509). This issue is for fixing memoryview. > 4. PyObject_GetBuffer needs to raise an exception if it sees ndim > 0 > with a NULL shape array in the resulting Py_buffer. I'm for it, except that we must make sure that nobody really relies on the current behaviour. I'm not sure there's only array.array. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:24:22 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2008 23:24:22 +0000 Subject: [issue4592] Embedding example does not add created module In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228865062.32.0.272578677361.issue4592@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: See attached documentation patch. Instead of a direct call to PyModule_Create(), the main function must use PyImport_AppendInittab("emb", &PyInit_emb); Note that the same line also works for all 2.x versions. I'll try to add an item to howto/cporting.rst. ---------- keywords: +needs review, patch Added file: http://bugs.python.org/file12310/embedding_example.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:43:19 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2008 23:43:19 +0000 Subject: [issue4613] Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za> Message-ID: <1228866199.42.0.286337254845.issue4613@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Somehow you caught the only SyntaxError that forgets to add filename and line information. Patch attached, at the expense of not displaying the variable name (it should be obvious if the line is displayed) ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file12311/syntaxerror.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:48:30 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2008 23:48:30 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228866510.19.0.907928370861.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for your comments, Alexander. Here's a rewritten version of the patch that's better commented and somewhat less convoluted; I think it should be easier to verify the correctness of this one. Added file: http://bugs.python.org/file12312/long_as_double2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:49:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 09 Dec 2008 23:49:19 +0000 Subject: [issue4592] Embedding example does not add created module In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za> Message-ID: <1228866559.9.0.10359358655.issue4592@psf.upfronthosting.co.za> Georg Brandl added the comment: Applied in r67682. Please don't add things directly to cporting.rst, rather amend the PortingExtensionModulesToPy3k wiki page. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:04:01 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 10 Dec 2008 00:04:01 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228867441.39.0.312361438013.issue4604@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: - The patch corrects a specific case, but not others: for example if the file is opened in "r" (text) mode. There are also other methods to test: peek(), read1()... - It should use self._checkClosed() which already raises the same exception with the same message. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 02:31:52 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 10 Dec 2008 01:31:52 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228867441.39.0.312361438013.issue4604@psf.upfronthosting.co.za> Message-ID: <18751.7171.105821.760414@montanaro-dyndns-org.local> Skip Montanaro added the comment: Amaury> - It should use Amaury> self._checkClosed() Amaury> which already raises the same exception with the same message. I think some other places will need this change then. Note that I don't know the io code at all. I was just trying to provide a simple test case and a simple fix. Feel free to generalize it as necessary. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 03:48:00 2008 From: report at bugs.python.org (Tom Pinckney) Date: Wed, 10 Dec 2008 02:48:00 +0000 Subject: [issue4615] de-duping function in itertools In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za> Message-ID: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za> New submission from Tom Pinckney : Any interest in an itertools de-duping function? I find I have to write this over and over for different projects: def deduped(iter,key=None): keys = set() for x in iter: if key: k = key(x) else: k = x if k in keys: continue keys.add(k) yield(x) ---------- components: Library (Lib) messages: 77477 nosy: thomaspinckney3 severity: normal status: open title: de-duping function in itertools type: feature request versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 03:50:09 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Dec 2008 02:50:09 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228877409.34.0.224572049837.issue3999@psf.upfronthosting.co.za> STINNER Victor added the comment: New patch: - limit memory footprint: use a static buffer to store the frames, with a maximum of MAXDEPTH frames (default: MAXDEPTH=100) - if there are more than MAXDEPTH frames, jump to the frame MAXDEPTH on error (it's like a truncated traceback) - don't call segfault_exit() in PyEval_EvalFrameEx() if segfault_enter() was not called On Ubuntu Gutsy, for MAXDEPTH=100 the memory footprint is 19996 bytes. I think that it's small, but it's possible to reduce the footprint by using less frames or disable the alternative stack (needed for stack overflow errors). Added file: http://bugs.python.org/file12313/segfault-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 03:50:14 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Dec 2008 02:50:14 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228877414.48.0.650794353266.issue3999@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file11666/segfault-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 03:54:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Dec 2008 02:54:19 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228877659.77.0.953829873679.issue3999@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, another change in segfault-3.patch: - disable signal handler before the first call to segfault_enter() and the last call to segfault_exit() About the memory footprint: it would be possible to use variable size buffer using malloc() and then realloc(). But static buffers are easier to use, and I don't want to play with malloc() while I'm handling a segmentation fault or stack overflow :-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 03:59:45 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2008 02:59:45 +0000 Subject: [issue4613] Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za> Message-ID: <1228877985.12.0.0936917427731.issue4613@psf.upfronthosting.co.za> Benjamin Peterson added the comment: +1 compiler_error should be used anyway. ---------- keywords: -needs review nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 04:00:13 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2008 03:00:13 +0000 Subject: [issue4615] de-duping function in itertools In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za> Message-ID: <1228878013.55.0.949013913527.issue4615@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 04:01:27 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2008 03:01:27 +0000 Subject: [issue4614] Document PyModule_Create() In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za> Message-ID: <1228878087.9.0.980760781844.issue4614@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- keywords: +needs review nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 04:06:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 10 Dec 2008 03:06:16 +0000 Subject: [issue4615] de-duping function in itertools In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za> Message-ID: <1228878376.62.0.511404001475.issue4615@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Am curious about your use cases. In what contexts are you needing to eliminate duplicates but retain the original ordering? Am wondering if the proposals for an ordered dictionary will meet your needs? Also, am looking to see what typifies the balance of needs your use cases -- an iterator so large that you wouldn't want to loop over it twice but a set of unique items that doesn't grow especially large (see the code random.sample for a similar situation). Another thought is that the proposal for a Bag class (multiset) may solve the problem more generally. ---------- versions: +Python 2.7, Python 3.1 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 04:47:20 2008 From: report at bugs.python.org (Tom Pinckney) Date: Wed, 10 Dec 2008 03:47:20 +0000 Subject: [issue4615] de-duping function in itertools In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za> Message-ID: <1228880840.7.0.942789090503.issue4615@psf.upfronthosting.co.za> Tom Pinckney added the comment: My latest need for something like this was something like this: src1 = db_query(query_1) src2 = db_query(query_2) results = deduped(src1 + src2, key=lambda x: x.field2) Basically, I wanted data from src1 if it existed and otherwise from src2 , while preserving the order of src1 (I didn't care about order of src2). A previous example was reading from a file and wanting to de-dupe lines based on a field in each line. Again order mattered to me since I wanted to process the non-duped lines in the file in order. A final example was generating a bunch of error messages from a variety of sources and then wanting to make sure there were no duplicate errors. Instead of: errors = set(errors) I find this much clearer: errors = deduped(errors) In reality all of these examples probably do not need to be written as a generator. The lists being de-duped are probably not so huge in practice as to preclude instantiating a new list (given the reality of multi-gig RAM machines etc). It just seemed particularly clear to write this using a yield. An ordered dictionary would probably work for me too. I don't think a Bag would given it's lack of ordering. I do find it very simple to just be able to apply deduped() to any existing sequence/iterator and not have to be more verbose about explicitly iterating and filling in an ordered dictionary somehow. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 05:44:36 2008 From: report at bugs.python.org (Albert Hopkins) Date: Wed, 10 Dec 2008 04:44:36 +0000 Subject: [issue4613] Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za> Message-ID: <1228884276.92.0.165718317441.issue4613@psf.upfronthosting.co.za> Albert Hopkins added the comment: Thanks for looking into this. Ok... I applied your patch (actually it does not apply against Python 3.0 so I had to change it manually). Now I'm not sure if this is still an error in the compiler or if it's truly a problem on my end, but the line given in the error doesn't contain a del statement at all. The code basically looks like this: def method(self): ... success = False e = None try: success, mydepgraph, dropped_tasks = resume_depgraph( self.settings, self.trees, self._mtimedb, self.myopts, myparams, self._spinner, skip_unsatisfied=True) except depgraph.UnsatisfiedResumeDep as e: mydepgraph = e.depgraph dropped_tasks = set() With the patch, the error occurs at "dropped_tasks = set()" in the except clause. The first time that "dropped_tasks" is used in the entire module is in the try clause. This is a horrible piece of code (I did not write it). Do you think the SyntaxError message could be masking what the real error is? Again, the python2 version of this module imports fine, but when I run 2to3 on it I get the SyntaxError. The line of code in question, however, is unmodified by 2to3. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 07:13:28 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Wed, 10 Dec 2008 06:13:28 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228889608.49.0.367920472243.issue4589@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: It's a corner case that would confuse anyone who ran into it, so I'm happy to backport it. I'll probably just re-do your patch on the 2.5 branch since WITH_CLEANUP has a different structure there. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 08:11:20 2008 From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=) Date: Wed, 10 Dec 2008 07:11:20 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> New submission from Horv?th Istv?n R?bert : tarfile does not set the creation date and time of the extracted directories, all extracted directories will get the date and time of the extraction, although in the source archive (created by tarfile) the creation date and time is stored for directories, too. ---------- components: Windows messages: 77485 nosy: throbi severity: normal status: open title: tarfile does not set the creation date and time of the extracted directories type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 08:25:51 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 07:25:51 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228893951.18.0.755867601162.issue4616@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I cannot reproduce this; it works fine for me. Can you provide a test case? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 08:50:04 2008 From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=) Date: Wed, 10 Dec 2008 07:50:04 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228895404.95.0.902405165705.issue4616@psf.upfronthosting.co.za> Horv?th Istv?n R?bert added the comment: Sure, see the attachment. Just call: python pack.py unpack directory.tar You should get the folder named "directory" dated to the current date and time. Added file: http://bugs.python.org/file12314/testcase.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:05:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:05:32 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228896332.56.0.0978594651629.issue4616@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I still cannot reproduce this: martin at mira:/tmp/h$ ls -l insgesamt 12 -rw-r--r-- 1 martin martin 172 10. Dez 08:40 directory.tar -rw-r--r-- 1 martin martin 1497 25. Feb 2008 pack.py -rw-r--r-- 1 martin martin 1129 10. Dez 08:58 testcase.zip martin at mira:/tmp/h$ date Mi 10. Dez 09:02:49 CET 2008 martin at mira:/tmp/h$ python pack.py unpack directory.tar Unpack done. martin at mira:/tmp/h$ ls -l insgesamt 16 drwxrwxrwx 2 martin martin 4096 10. Dez 08:38 directory -rw-r--r-- 1 martin martin 172 10. Dez 08:40 directory.tar -rw-r--r-- 1 martin martin 1497 25. Feb 2008 pack.py -rw-r--r-- 1 martin martin 1129 10. Dez 08:58 testcase.zip As you can see, directory is dated 8:38, even though the current time is 9:02. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:15:15 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:15:15 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za> Message-ID: <1228896915.2.0.573622519652.issue4342@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm skeptical about backporting r59654. Doing so might break existing applications. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:21:42 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:21:42 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za> Message-ID: <1228897302.15.0.0167451283154.issue4342@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you remind me what problem was fixed with r59653? I can't find the Tk tracker anymore on which this apparently was reported. If it fixes a problem with supporting Tcl 8.5, then I will also reject the request. Supporting Tcl 8.5 is a new feature, and should thus not be added to 2.5.3. Only Tcl up to 8.4 is support by Python 2.5. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:22:55 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:22:55 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1228897375.23.0.685594189615.issue4533@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:23:23 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:23:23 +0000 Subject: [issue4532] Fails to build on QNX 6.3.2 In-Reply-To: <1228415114.24.0.8798028778.issue4532@psf.upfronthosting.co.za> Message-ID: <1228897403.24.0.047727482026.issue4532@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:23:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:23:48 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1228897428.88.0.210040194347.issue4449@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:24:26 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:24:26 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1228897467.0.0.462290288976.issue4565@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:24:53 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:24:53 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228897493.46.0.0608172678411.issue4561@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:25:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:25:12 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1228897512.74.0.230110993573.issue1717@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:25:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:25:32 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1228897532.51.0.883974174795.issue4604@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:26:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:26:48 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1228897608.74.0.470836394313.issue4303@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thomas, do you have an idea what might be causing this problem, or a proposal how to resolve it? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:28:44 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:28:44 +0000 Subject: [issue2810] _winreg.EnumValue fails when the registry data includes multibyte unicode characters In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za> Message-ID: <1228897724.89.0.170751075988.issue2810@psf.upfronthosting.co.za> Martin v. L?wis added the comment: IIUC, no fix for this bug has been proposed, so the issue is no candidate for 2.5.3. ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:29:44 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:29:44 +0000 Subject: [issue3924] cookielib chokes on non-integer cookie version, should ignore it instead In-Reply-To: <1222021824.75.0.209543556591.issue3924@psf.upfronthosting.co.za> Message-ID: <1228897784.01.0.114825574501.issue3924@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As the patch hasn't been applied to the trunk yet, I'm rejecting it for 2.5.3. ---------- nosy: +loewis versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:30:26 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:30:26 +0000 Subject: [issue4212] email.LazyImporter does not use absolute imports In-Reply-To: <1225087041.33.0.0357186656553.issue4212@psf.upfronthosting.co.za> Message-ID: <1228897826.78.0.922939364885.issue4212@psf.upfronthosting.co.za> Martin v. L?wis added the comment: No patch has been proposed, so the issue is not eligible for 2.5.3. ---------- nosy: +loewis versions: +Python 2.6 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:31:50 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:31:50 +0000 Subject: [issue4222] dis.findlinestarts is missing from dis.__all__ and from the online documentation In-Reply-To: <1225214206.66.0.527749553778.issue4222@psf.upfronthosting.co.za> Message-ID: <1228897910.03.0.725586195101.issue4222@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Such a change is out of scope for maintenance releases (in any case, no resolution has been proposed, yet). ---------- nosy: +loewis versions: +Python 2.7 -Python 2.4, Python 2.5, Python 2.5.3, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:32:43 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:32:43 +0000 Subject: [issue4177] Crash in MIMEText on FreeBSD In-Reply-To: <1224700839.13.0.201844476382.issue4177@psf.upfronthosting.co.za> Message-ID: <1228897963.18.0.293712005966.issue4177@psf.upfronthosting.co.za> Martin v. L?wis added the comment: IIUC, no patch has been proposed. So retargetting it to later versions. ---------- nosy: +loewis versions: +Python 2.7 -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:34:17 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:34:17 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1228898057.37.0.871674176686.issue4228@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you provide a fix within the next two days? Otherwise, I see little chance that this gets fixed in 2.5. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:35:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:35:13 +0000 Subject: [issue4259] Update pydoc URLs In-Reply-To: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za> Message-ID: <1228898113.45.0.150914999198.issue4259@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch is fine; please apply. ---------- assignee: -> akuchling nosy: +loewis priority: -> release blocker resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:35:53 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:35:53 +0000 Subject: [issue4278] optparse quirks In-Reply-To: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za> Message-ID: <1228898153.83.0.596541275348.issue4278@psf.upfronthosting.co.za> Martin v. L?wis added the comment: No patch proposed yet, so retargetting to trunk. ---------- nosy: +loewis versions: +Python 2.7 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:38:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:38:39 +0000 Subject: [issue4071] ntpath.abspath fails for long str paths In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za> Message-ID: <1228898319.18.0.307728099382.issue4071@psf.upfronthosting.co.za> Martin v. L?wis added the comment: ocean-city, can you please backport this to the 2.5 branch? ---------- assignee: -> ocean-city nosy: +loewis priority: -> release blocker resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:39:29 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:39:29 +0000 Subject: [issue4071] ntpath.abspath fails for long str paths In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za> Message-ID: <1228898369.01.0.704969846115.issue4071@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As a follow-up: please don't forget to add Misc/NEWS entries (both for the already-committed patch, as well as for the backport). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:40:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:40:49 +0000 Subject: [issue4185] re module treats raw strings as normal strings In-Reply-To: <1224734129.35.0.170011642262.issue4185@psf.upfronthosting.co.za> Message-ID: <1228898449.97.0.674589391745.issue4185@psf.upfronthosting.co.za> Martin v. L?wis added the comment: IIUC, there is no proposed patch yet, so this is out of scope for 2.5.3. ---------- nosy: +loewis versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:42:04 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:42:04 +0000 Subject: [issue4302] smtplib.py initialisation defect In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za> Message-ID: <1228898524.12.0.734801235834.issue4302@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Backporting is fine with me: any volunteers? ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:42:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:42:45 +0000 Subject: [issue2996] IDLE "find in files" output not formatted optimally In-Reply-To: <1212008945.94.0.774872087064.issue2996@psf.upfronthosting.co.za> Message-ID: <1228898565.66.0.323237668601.issue2996@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:44:08 2008 From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=) Date: Wed, 10 Dec 2008 08:44:08 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228898648.38.0.884252486653.issue4616@psf.upfronthosting.co.za> Horv?th Istv?n R?bert added the comment: Sorry, I thought that by selecting component "Windows" from the first combo box I specify that this problem occurs on a windows machine. I run win xp sp2. As you can see in the screenshot, the unpacked directory has the current date and time. Added file: http://bugs.python.org/file12315/python_tarfile_win.JPG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:44:57 2008 From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=) Date: Wed, 10 Dec 2008 08:44:57 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228898697.21.0.0184510157005.issue4616@psf.upfronthosting.co.za> Changes by Horv?th Istv?n R?bert : Removed file: http://bugs.python.org/file12315/python_tarfile_win.JPG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:44:59 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:44:59 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1228898699.93.0.265274006769.issue3248@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What problem is solved by ScrolledText.diff that isn't already solved by scrolledtext_masterstr.diff? ---------- nosy: +loewis priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:46:33 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:46:33 +0000 Subject: [issue3767] tkColorChooser may fail if no color is selected In-Reply-To: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za> Message-ID: <1228898793.62.0.305285702488.issue3767@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:47:33 2008 From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=) Date: Wed, 10 Dec 2008 08:47:33 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228898853.83.0.507808162596.issue4616@psf.upfronthosting.co.za> Changes by Horv?th Istv?n R?bert : Added file: http://bugs.python.org/file12316/python_tarfile_win.JPG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:47:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:47:49 +0000 Subject: [issue4379] Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za> Message-ID: <1228898869.78.0.958634684736.issue4379@psf.upfronthosting.co.za> Martin v. L?wis added the comment: IIUC, the patch relies on VS 2008. So it is not a candidate for 2.5.3. ---------- nosy: +loewis versions: +Python 2.6, Python 2.7 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:48:47 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:48:47 +0000 Subject: =?utf-8?q?[issue4328]_"=C3=A0"_in_u"foo"_raises_a_misleading_error?= In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za> Message-ID: <1228898927.75.0.143531839382.issue4328@psf.upfronthosting.co.za> Martin v. L?wis added the comment: No patch has been proposed yet, so un-targetting for bugfix branches. ---------- nosy: +loewis versions: -Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:49:47 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:49:47 +0000 Subject: [issue4416] state_reset not called on 'state' before sre_search invoked In-Reply-To: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za> Message-ID: <1228898987.69.0.0717548532014.issue4416@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you provide a test case demonstrating a problem? ---------- nosy: +loewis versions: +Python 2.7 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:50:31 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:50:31 +0000 Subject: [issue4446] Distutils Metadata Documentation Missing "platforms" Keyword In-Reply-To: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za> Message-ID: <1228899031.92.0.802569516183.issue4446@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:53:00 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:53:00 +0000 Subject: [issue1533] Bug in range() function for large values In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za> Message-ID: <1228899180.44.0.164319117197.issue1533@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This change is out of scope for 2.5.3 (plus, the desired behavior still seems to be debated) ---------- nosy: +loewis versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:54:58 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:54:58 +0000 Subject: [issue4508] distutils compiler not handling spaces in path to output/src files In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za> Message-ID: <1228899298.48.0.322905366704.issue4508@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch hasn't been accepted for the trunk, yet, so it is not a candidate for a 2.5 backport. ---------- nosy: +loewis versions: -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:55:56 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:55:56 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1228899356.27.0.864011626239.issue4197@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The precise solution still seems to be debated, so this is out of scope for 2.5.3. ---------- nosy: +loewis versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:57:15 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:57:15 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za> Message-ID: <1228899435.06.0.947053346364.issue4201@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch hasn't been accepted for the trunk, yet, so it is out of scope for 2.5.3. Retargetting. ---------- nosy: +loewis versions: +Python 2.7 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:58:56 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:58:56 +0000 Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11 In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za> Message-ID: <1228899536.2.0.243102669751.issue4368@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:59:33 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 08:59:33 +0000 Subject: [issue4567] Registry key not set if unattended installation used In-Reply-To: <1228587246.7.0.370739440379.issue4567@psf.upfronthosting.co.za> Message-ID: <1228899573.7.0.408297998584.issue4567@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:00:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:00:48 +0000 Subject: [issue4568] Improved optparse "varargs" callback example In-Reply-To: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za> Message-ID: <1228899648.05.0.826300723996.issue4568@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The 2.5 documentation is not in .rst, so I remove these versions. ---------- nosy: +loewis versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:01:44 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:01:44 +0000 Subject: [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1228899704.89.0.120058326156.issue4335@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch has not been accepted for the trunk, so backporting it to 2.5.3 is out of scope at this point. ---------- nosy: +loewis versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:03:05 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:03:05 +0000 Subject: [issue4220] Builtins treated as free variables? In-Reply-To: <1225210788.32.0.89272753959.issue4220@psf.upfronthosting.co.za> Message-ID: <1228899785.59.0.669465304577.issue4220@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There is no proposed patch yet, so this is out of scope for 2.5.3. ---------- nosy: +loewis versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:04:30 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:04:30 +0000 Subject: [issue416670] MatchObjects not deepcopy()able Message-ID: <1228899870.25.0.201270469583.issue416670@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As far as I can tell, there is no proposed patch. So this is out of scope for 2.5.3. ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:05:29 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:05:29 +0000 Subject: [issue4555] Smelly exports In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za> Message-ID: <1228899929.81.0.310752588249.issue4555@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There is no proposed patch yet, so removing 2.5.3 from the target versions. ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:08:06 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:08:06 +0000 Subject: [issue4084] Decimal.max(NaN, x) gives incorrect results when x is finite and long In-Reply-To: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za> Message-ID: <1228900086.2.0.0356845621019.issue4084@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Unless Facundo or some of the other decimal contributors reviews and applies this patch really quickly, it is out of scope for 2.5.3. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:09:09 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:09:09 +0000 Subject: [issue858809] Use directories from configure rather than hardcoded Message-ID: <1228900149.96.0.00779578368231.issue858809@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:10:00 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:10:00 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1228900200.78.0.374426808386.issue1706039@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:10:40 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:10:40 +0000 Subject: [issue1711800] SequenceMatcher bug with insert/delete block after "replace" Message-ID: <1228900240.5.0.0289432383789.issue1711800@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Without a patch, this is not a candidate for 2.5.3. ---------- nosy: +loewis versions: +Python 2.7 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:14:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:14:12 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1228900452.65.0.529390630436.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:14:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:14:25 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1228900465.69.0.571800646812.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:15:33 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:15:33 +0000 Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386 In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za> Message-ID: <1228900533.98.0.90193674052.issue3863@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:16:56 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:16:56 +0000 Subject: [issue1868] threading.local doesn't free attrs when assigning thread exits In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> Message-ID: <1228900616.39.0.1983117076.issue1868@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Since no specific patch was proposed for 2.5.3, I'm untargetting it for 2.5. ---------- versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:19:57 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:19:57 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228900797.5.0.892786853821.issue4616@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you debug this? Where specifically does the problem occur? ---------- assignee: -> lars.gustaebel nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:20:30 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 10 Dec 2008 09:20:30 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1228900830.57.0.249455904264.issue4303@psf.upfronthosting.co.za> Thomas Heller added the comment: Is this really a regression? I do not think so; the libffi library included with the Python 2.5 ctypes does not support closures on the arm. See file Modules/_ctypes/libffi/src/arm/ffitarget.h, it contains '#define FFI_CLOSURES 0'. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:28:38 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 10 Dec 2008 09:28:38 +0000 Subject: [issue4071] ntpath.abspath fails for long str paths In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za> Message-ID: <1228901318.59.0.156923687807.issue4071@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: >can you please backport this to the 2.5 branch? Sorry for clarification. Which should I backport r67154 or quick_hack_for_getfullpathname_v2.patch? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:38:17 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 09:38:17 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1228901897.53.0.278945278451.issue4303@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The question is whether it used to build in 2.5.2, but doesn't build anymore now. If that's what happening, it is a regression. It seems that ffi_info moved into ctypes.h: could that have caused the breakage? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:43:57 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 10 Dec 2008 09:43:57 +0000 Subject: [issue4613] Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za> Message-ID: <1228902237.68.0.861378090902.issue4613@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I think I understand. This simple code does not compile with python 3.0: def f(): e = None def g(): e try: pass except Exception as e: pass # SyntaxError here??? The reason is that since 3.0, a "del e" statement is generated by the compiler (see http://www.python.org/dev/peps/pep-3110/#semantic-changes) and this conflicts with the first block of the function. This issue is much more complicated than it seemed... A solution could be to generate "e=None" instead of "del e". ---------- priority: -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:44:11 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 10 Dec 2008 09:44:11 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za> Message-ID: <1228902251.27.0.855534999134.issue4610@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Python uses the Unicode database for the mapping and this only contains 1-1 mappings. The special cases (mostly 1-2 mappings) are not included. It would be nice to have them available as well, but I guess we'd have to write them in code rather than invent a new mapping table for them. Furthermore, there are a few cases like e.g. the Turkish i where case mappings depend on external context such as the language the code point is used in - those cases are difficult to get right. We may need to extend the .lower()/.upper()/.title() methods with an optional parameter that allow providing this extra context information to the methods. BTW: '?' is being phased out in German. The new writing rules encourage using 'ss' or 'SS' instead (which is not entirely correct, since '?' originated from 'sz' used some hundred or so years ago, but those are just details ;-). ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:47:24 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 10 Dec 2008 09:47:24 +0000 Subject: [issue4302] smtplib.py initialisation defect In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za> Message-ID: <1228902444.87.0.209510919436.issue4302@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I will backport this. ---------- assignee: -> ocean-city _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:56:19 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 10 Dec 2008 09:56:19 +0000 Subject: [issue4302] smtplib.py initialisation defect In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za> Message-ID: <1228902979.43.0.761391624077.issue4302@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Done. Fixed in r67686 (release25-maint). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 11:13:45 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 10 Dec 2008 10:13:45 +0000 Subject: [issue1711800] SequenceMatcher bug with insert/delete block after "replace" Message-ID: <1228904025.08.0.840440355762.issue1711800@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Tim, any comments or interest? ---------- assignee: -> tim_one nosy: +rhettinger, tim_one _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 11:15:05 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Wed, 10 Dec 2008 10:15:05 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228904105.33.0.224995233498.issue4616@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Directory times are explicitly not set. The comment in TarFile.utime() says that it is an error on Windows to use utime on directories. I am no Windows expert, so I don't know if that is still true. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 11:21:23 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 10 Dec 2008 10:21:23 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1228904483.45.0.776905856448.issue4303@psf.upfronthosting.co.za> Thomas Heller added the comment: > It seems that ffi_info moved into ctypes.h: could that have caused the > breakage? Not sure what you mean exactly (there is no ffi_info in ctypes.h), but I assume you are referring to svn rev. 62504? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 12:04:40 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Wed, 10 Dec 2008 11:04:40 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1228907080.96.0.998382391787.issue4616@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Apparently it is not. os.utime() was fixed for Windows in Python 2.5 (r45925), so it should be possible for tarfile to set directory times now. I will prepare a patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 12:07:38 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Dec 2008 11:07:38 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228907258.56.0.867966783989.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: The reason memoryview's current len() implementation is wrong is because its indexing is per element in the original object, not per byte: >>> a = array('i', range(10)) >>> m = memoryview(a) >>> for i in range(len(m)): ... print(m[i]) ... b'\x00\x00\x00\x00' b'\x01\x00\x00\x00' b'\x02\x00\x00\x00' b'\x03\x00\x00\x00' b'\x04\x00\x00\x00' b'\x05\x00\x00\x00' b'\x06\x00\x00\x00' b'\x07\x00\x00\x00' b'\x08\x00\x00\x00' b'\t\x00\x00\x00' Traceback (most recent call last): File "", line 2, in IndexError: index out of bounds Oops. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 12:09:39 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Dec 2008 11:09:39 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228907379.98.0.297531129759.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding ndim > 0 and shape=NULL, the PEP doesn't allow it. Any code that does it is already broken - we're just making it fail cleanly at the point where it is broken rather than in some obscure fashion somewhere else. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 12:32:10 2008 From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=) Date: Wed, 10 Dec 2008 11:32:10 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228907080.96.0.998382391787.issue4616@psf.upfronthosting.co.za> Message-ID: <73d49ba90812100332u61e527c6l48320167b508f5fd@mail.gmail.com> Horv?th Istv?n R?bert added the comment: Wooow, you're fast! :-) We use Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32, so that will help us! Thank you, Robert On Wed, Dec 10, 2008 at 12:04 PM, Lars Gust?bel wrote: > > Lars Gust?bel added the comment: > > Apparently it is not. os.utime() was fixed for Windows in Python 2.5 > (r45925), so it should be possible for tarfile to set directory times > now. I will prepare a patch. > > _______________________________________ > Python tracker > > _______________________________________ > Added file: http://bugs.python.org/file12317/unnamed _______________________________________ Python tracker _______________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed URL: From report at bugs.python.org Wed Dec 10 13:18:43 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 10 Dec 2008 12:18:43 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : This issue comes from issue4613. The following code raises a SyntaxError("can not delete variable 'e' referenced in nested scope"): def f(): e = None def g(): e try: pass except Exception as e: pass # SyntaxError here??? The reason is because of http://www.python.org/dev/peps/pep-3110/#semantic-changes, a "del e" statement is inserted. The above code is correct, and should work. I suggest that the limitation: "can not delete variable referenced in nested scope" could be removed. After all, the "variable referenced" has no value before it is set, accessing it raises either NameError("free variable referenced before assignment in enclosing scope") or UnboundLocalError("local variable referenced before assignment") The Attached patch adds a DELETE_DEREF opcode, that removes the value of a cell variable, and put it in a "before assignment" state. Some compiler experts should review it. Few regressions are possible, since the new opcode is emitted where a SyntaxError was previously raised. The patch could also be applied to 2.7, even if it is less critical there. Tests are to come, but I'd like other's suggestions. ---------- files: delete_deref.patch keywords: needs review, patch messages: 77536 nosy: amaury.forgeotdarc priority: release blocker severity: normal status: open title: SyntaxError when free variable name is also an exception target versions: Python 2.7, Python 3.0 Added file: http://bugs.python.org/file12318/delete_deref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 13:26:36 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 10 Dec 2008 12:26:36 +0000 Subject: [issue4613] Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za> Message-ID: <1228911996.31.0.766964824102.issue4613@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I filed issue4617 about the hidden "del e" problem. Meanwhile, you may try to change some variable names, specially the exception target (the 'e' in 'except Exception as e') ---------- assignee: -> amaury.forgeotdarc priority: critical -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 13:57:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 10 Dec 2008 12:57:40 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228907379.98.0.297531129759.issue4580@psf.upfronthosting.co.za> Message-ID: <1228913861.8401.1.camel@localhost> Antoine Pitrou added the comment: Thanks for your two messages, Nick, they make things clearer for me and I'll make the necessary modifications in the patch some time today. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 14:19:06 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 10 Dec 2008 13:19:06 +0000 Subject: [issue4618] print_function and unicode_literals don't work together In-Reply-To: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za> Message-ID: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone : Consider: exarkun at charm:~$ ~/Projects/python/branches/release26-maint/python Python 2.6+ (trunk:66997, Oct 23 2008, 16:02:09) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def f(o): ... print type(o) ... >>> f('foo') >>> from __future__ import unicode_literals >>> f('foo') >>> from __future__ import print_function >>> print('foo') foo >>> from io import StringIO >>> print('foo', file=StringIO()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/branches/release26-maint/Lib/io.py", line 1487, in write s.__class__.__name__) TypeError: can't write str to text stream >>> StringIO().write('foo') 3 >>> StringIO().write(b'foo') Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/branches/release26-maint/Lib/io.py", line 1487, in write s.__class__.__name__) TypeError: can't write str to text stream >>> It seems the type of a literal string is `str? when it is an argument to the print function, even with the unicode_literals future import in effect. ---------- components: Interpreter Core messages: 77539 nosy: exarkun severity: normal status: open title: print_function and unicode_literals don't work together versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 14:38:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Dec 2008 13:38:19 +0000 Subject: [issue4618] print_function and unicode_literals don't work together In-Reply-To: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za> Message-ID: <1228916299.4.0.0841762413467.issue4618@psf.upfronthosting.co.za> STINNER Victor added the comment: The TypeError("can't write str to text stream") comes from the newline written by builtin_print(). Workaround: print(u"foo", end=u"\n", file=StringIO()). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 14:55:37 2008 From: report at bugs.python.org (Robert Hunger) Date: Wed, 10 Dec 2008 13:55:37 +0000 Subject: [issue4619] Invalid Behaviour When a Default Argument is a Mutable Object In-Reply-To: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za> Message-ID: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za> New submission from Robert Hunger : Reopening of issue 4181. Evaluating default parameter values when the function definition is executed is a design bug. Even the documentation of this behaviour (see http://docs.python.org/reference/compound_stmts.html#index-754) makes this clear by stating: "This is generally not what was intended." It then makes a suggestion for a workaround ("A way around this ..."). Only bugs need workarounds. An interface or behaviour should fulfil a users expectation for the "normal" case, not for some "special" case. For a default parameter value a user expects that whenever this function gets called a new instance of a mutable object is created. This is much closer to the current behaviour for non-mutable objects. Usage cases for the current default behaviour are less common. ---------- components: Interpreter Core messages: 77541 nosy: Pasha2009, christian.heimes, rhr severity: normal status: open title: Invalid Behaviour When a Default Argument is a Mutable Object type: behavior versions: Python 2.4, Python 2.5, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:27:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 10 Dec 2008 14:27:57 +0000 Subject: [issue4619] Invalid Behaviour When a Default Argument is a Mutable Object In-Reply-To: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za> Message-ID: <1228919277.17.0.786706782729.issue4619@psf.upfronthosting.co.za> Christian Heimes added the comment: No, it is NOT a bug. The behavior will NOT chance. I'm marking this bug as a documentation issue. ---------- assignee: -> georg.brandl components: +Documentation -Interpreter Core nosy: +georg.brandl versions: +Python 2.6, Python 2.7, Python 3.1 -Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:40:58 2008 From: report at bugs.python.org (BEGUE) Date: Wed, 10 Dec 2008 14:40:58 +0000 Subject: [issue4620] Memory leak with datetime used with time.strptime In-Reply-To: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za> Message-ID: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za> New submission from BEGUE : When I use the following line in my process (my process run these line each 10 seconds), memory size increases progressively : myDate = datetime.datetime(*(time.strptime(dateString, "%Y-%m-%dT%H:%M:%S")[0:6])) the '*' operator unpacks the tuple, producing the argument list for datetime.datetime but it seems that the structure return by time.strptime is not correctly flushed in memory. ---------- components: None messages: 77543 nosy: sebegue severity: normal status: open title: Memory leak with datetime used with time.strptime type: resource usage versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:44:44 2008 From: report at bugs.python.org (=?utf-8?q?Reto_Sch=C3=BCttel?=) Date: Wed, 10 Dec 2008 14:44:44 +0000 Subject: [issue2734] 2to3 converts long(itude) argument to int In-Reply-To: <1209669660.53.0.857681626906.issue2734@psf.upfronthosting.co.za> Message-ID: <1228920284.09.0.318119758916.issue2734@psf.upfronthosting.co.za> Reto Sch?ttel added the comment: This is even worse in case of attributes (like in pyephem for the observer object): class Foo(object): def __init__(self): self.long = 1 x = Foo() print x.long 2to3 produces: --- attr.py (original) +++ attr.py (refactored) @@ -1,6 +1,6 @@ class Foo(object): def __init__(self): - self.long = 1 + self.int = 1 x = Foo() -print x.long +print(x.int) I think 2to3 shouldn't refactor any attribute names. I doubt anybody would access the type long using an attribute :). Cheers, Reto ---------- nosy: +retoo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:45:10 2008 From: report at bugs.python.org (Robin Stocker) Date: Wed, 10 Dec 2008 14:45:10 +0000 Subject: [issue2734] 2to3 converts long(itude) argument to int In-Reply-To: <1209669660.53.0.857681626906.issue2734@psf.upfronthosting.co.za> Message-ID: <1228920310.99.0.732935178401.issue2734@psf.upfronthosting.co.za> Changes by Robin Stocker : ---------- nosy: +robin.stocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:56:00 2008 From: report at bugs.python.org (=?utf-8?q?Gr=C3=A9goire_Weber?=) Date: Wed, 10 Dec 2008 14:56:00 +0000 Subject: [issue4619] Invalid Behaviour When a Default Argument is a Mutable Object In-Reply-To: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za> Message-ID: <1228920960.37.0.690941807229.issue4619@psf.upfronthosting.co.za> Gr?goire Weber added the comment: I'd like to second rhr. The current behaviour is is not according to Pythons design principle of least surprise. After 5+ years of Python experience as Zope and Plone developer I recently fell into that trap. ----- Just for information (Discussion thread on a Pre-PEP started Feb 14, 2007: http://mail.python.org/pipermail/python-3000/2007-February/005704.html The BDFL statement to this: http://mail.python.org/pipermail/python-3000/2007-February/005715.html ---------- nosy: +gregweb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:57:38 2008 From: report at bugs.python.org (Elizabeth Chang) Date: Wed, 10 Dec 2008 14:57:38 +0000 Subject: [issue4598] IDLE not opening In-Reply-To: <1228860949.85.0.139875505378.issue4598@psf.upfronthosting.co.za> Message-ID: <07B7870CE4945841951B429C10A4C929900C7E@email1.mitretek.org> Elizabeth Chang added the comment: It is working now though so there is no error message anymore. I had to move tk and tcl Python25/Lib. When I hadn't done that, it said it was looking for tk8.4 under a series of directories and it didn't find it. When I moved tk8.4 folder to under Python25/Lib, it complained about not being able to find tcl8.4. So I found that directory under Python25/Tcl and moved it to Python25/Lib. - Elizabeth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:05:05 2008 From: report at bugs.python.org (Travis Oliphant) Date: Wed, 10 Dec 2008 15:05:05 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228921505.12.0.74177803214.issue4580@psf.upfronthosting.co.za> Travis Oliphant added the comment: I will take some time in the next week to look at this issue. Thank you for bringing these bugs to my attention. I did not finish the memoryview implementation, due to other demands on my time. I appreciate the efforts of so many to pick up and understand the PEP and contribute code. I've noticed some incorrect statements being passed around, and I apologize for not providing a perspective on them. I hope there is a clear distinction between the buffer protocol and the memoryview object. The buffer protocol was thought through fairly well, but the memoryview object has not received the same attention. My mental model of the memoryview object is basically an (enhanced) NumPy array without the math support. It does not suprise me that there are a few remaining issues in the memoryview object. However, I'm confident they can be cleared up. A few changes to the code were made by others without changing the PEP. I accept responsibility for this because people were cleaning up what I should have already finished. All the help is appreciated. I will review the patches and fix the problem. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:13:35 2008 From: report at bugs.python.org (Travis Oliphant) Date: Wed, 10 Dec 2008 15:13:35 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228922015.2.0.216807647566.issue4580@psf.upfronthosting.co.za> Travis Oliphant added the comment: My perspective on statements made: * Memoryview object should report it's length as self->view.shape[0] unless self->view.shape is NULL (indicating in this case a 0-d array or scalar). In this case, it should raise an error. * The buffer protocol is clear about who owns the memory for shape and strides (and suboffsets). The exporter does and it is responsible for not changing them until releasebuffer is called. * It should also be clear that shape, strides, and suboffsets will be NULL in exactly two cases 1) The corresponding flag was not set indicating the consumer is not interested in shape, strides, or suboffsets 2) ndim == 0 indicating a 0-dimensional array (scalar-like). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:14:44 2008 From: report at bugs.python.org (David W. Lambert) Date: Wed, 10 Dec 2008 15:14:44 +0000 Subject: [issue4619] Invalid Behaviour When a Default Argument is a Mutable Object In-Reply-To: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za> Message-ID: <1228922084.06.0.449657229967.issue4619@psf.upfronthosting.co.za> David W. Lambert added the comment: Mutable function arguments and class variables are python's mechanisms to provide data persistence at these scope levels. Quite opposite of design flaw, they are necessary! Write a decorator to change the behavior where you'd like an empty mutable defaults if you're not happy with other methods already described. ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:22:03 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 10 Dec 2008 15:22:03 +0000 Subject: [issue4620] Memory leak with datetime used with time.strptime In-Reply-To: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za> Message-ID: <1228922523.77.0.221150961317.issue4620@psf.upfronthosting.co.za> Skip Montanaro added the comment: Can you reproduce this with a script that does nothing more than while True: myDate = datetime.datetime(*(time.strptime("2008-12-10T14:00:03", "%Y-%m-%dT%H:%M:%S")[:6])) I tried with both Python 2.4.5 on Solaris and Python built from CVS (aka 2.7a0) on my Mac and see no memory growth of the processes. If there's a memory leak my guess is that it is somewhere else. ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:31:31 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Wed, 10 Dec 2008 15:31:31 +0000 Subject: [issue4620] Memory leak with datetime used with time.strptime In-Reply-To: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za> Message-ID: <1228923091.35.0.494311692715.issue4620@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: Tried it with Python 2.5.2 on WinXP, I see no memory growth either. ---------- nosy: +quentin.gallet-gilles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:33:43 2008 From: report at bugs.python.org (Travis Oliphant) Date: Wed, 10 Dec 2008 15:33:43 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228923223.15.0.534764323008.issue4580@psf.upfronthosting.co.za> Travis Oliphant added the comment: Another comment on statements made * I don't see where array.array getbuf implementation is broken. It looks correct to me. It sets view.shape to NULL unless the consumer asked for the shape information to be reported in which case it sets it equal to a pointer to the number of elements in the array. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:17:00 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 10 Dec 2008 16:17:00 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228923223.15.0.534764323008.issue4580@psf.upfronthosting.co.za> Message-ID: <1228925821.31006.2.camel@localhost> Antoine Pitrou added the comment: > * I don't see where array.array getbuf implementation is broken. It > looks correct to me. It sets view.shape to NULL unless the consumer > asked for the shape information to be reported in which case it sets it > equal to a pointer to the number of elements in the array. What I meant by that is that array.array frequently bypasses its own resize helper and calls PyMem_Resize directly instead. This is the likely cause of #4583. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:20:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 10 Dec 2008 16:20:36 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228922015.2.0.216807647566.issue4580@psf.upfronthosting.co.za> Message-ID: <1228926036.31006.5.camel@localhost> Antoine Pitrou added the comment: Thanks for your comments. I'll provide an updated patch later today and let you take a look. > * Memoryview object should report it's length as self->view.shape[0] > unless self->view.shape is NULL (indicating in this case a 0-d array or > scalar). In this case, it should raise an error. Are 0-d arrays (scalars) really useful? Could we make things simpler by simply removing support for them? > * The buffer protocol is clear about who owns the memory for shape and > strides (and suboffsets). The exporter does and it is responsible for > not changing them until releasebuffer is called. But how do we do when slicing a memoryview? The new (sliced) memoryview object clearly must alter the shape after the buffer has been filled in by the exporter. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:27:47 2008 From: report at bugs.python.org (Francesco Ricciardi) Date: Wed, 10 Dec 2008 16:27:47 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> New submission from Francesco Ricciardi : Each entry of a zip file, as read by the zipfile module, can be accessed via a ZipInfo object. The filename attribute of ZipInfo is a string. However, the read method of a ZipFile object expects a binary as argument, or at least this is what I can deduct from the following behavior: >>> import zipfile >>> testzip = zipfile.ZipFile('test.zip') >>> t1 = testzip.infolist()[0] >>> t1.filename 't?st.xml' >>> data = testzip.read(testzip.infolist()[0]) Traceback (most recent call last): File "", line 1, in File "C:\Python30\lib\zipfile.py", line 843, in read return self.open(name, "r", pwd).read() File "C:\Python30\lib\zipfile.py", line 883, in open % (zinfo.orig_filename, fname)) zipfile.BadZipfile: File name in directory 't?st.xml' and header b't\x82st.xml' differ. The test.zip file is attached as help in reproducing this error. ---------- components: Library (Lib) files: test.zip messages: 77555 nosy: francescor severity: normal status: open title: zipfile returns string but expects binary type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file12319/test.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:41:24 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 16:41:24 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1228927284.98.0.114964681165.issue4617@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 18:06:24 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 10 Dec 2008 17:06:24 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228928784.69.0.433184460582.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: Minor cleanup of long_as_double2.patch. Added file: http://bugs.python.org/file12320/long_as_double2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 18:06:32 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 10 Dec 2008 17:06:32 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1228928792.56.0.655349484119.issue3166@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12312/long_as_double2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 18:07:07 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 17:07:07 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1228928827.26.0.539270475651.issue4303@psf.upfronthosting.co.za> Martin v. L?wis added the comment: That's the revision I meant, yes. It seems that ffi_info just got renamed, so I misread the change. In any case, it's (now) unclear how this did compile before, as ffi_closure was always referenced in ctypes.h... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 18:08:02 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 17:08:02 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1228928882.47.0.603298670909.issue4303@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Unfortunately, the ARM buildbot is down right now, so no tests can be performed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 18:20:55 2008 From: report at bugs.python.org (eliben) Date: Wed, 10 Dec 2008 17:20:55 +0000 Subject: [issue4622] SequenceMatcher bug with long sequences In-Reply-To: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za> Message-ID: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za> New submission from eliben : Here's a reproduction of the error: Python 2.5.2 (r252:60911, Oct 20 2008, 09:11:31) [GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import difflib >>> >>> difflib.SequenceMatcher(None, [4] + [5] * 200, [5] * 200).ratio() 0.0 ratio() should be returning close to 1.0 here, not 0. This is only a problem for sequences longer than 200. The analogous run for 100: >>> difflib.SequenceMatcher(None, [4] + [5] * 100, [5] * 100).ratio() 0.99502487562189057 >>> I've managed to reproduce it on Linux, Windows (AS 2.5.2) and Try Python (http://try-python.mired.org/) ---------- components: Library (Lib) messages: 77559 nosy: eliben severity: normal status: open title: SequenceMatcher bug with long sequences versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 18:30:03 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 10 Dec 2008 17:30:03 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228930203.83.0.051501147577.issue4580@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch addressing the above issues. You can also review it at http://codereview.appspot.com/10441 Added file: http://bugs.python.org/file12321/issue4580-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:02:58 2008 From: report at bugs.python.org (David W. Lambert) Date: Wed, 10 Dec 2008 18:02:58 +0000 Subject: [issue4622] SequenceMatcher bug with long sequences In-Reply-To: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za> Message-ID: <1228932178.22.0.0687619584693.issue4622@psf.upfronthosting.co.za> David W. Lambert added the comment: Python 3.0rc1+ similar. ---------- nosy: +LambertDW versions: +Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:04:10 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 10 Dec 2008 18:04:10 +0000 Subject: [issue4185] re module treats raw strings as normal strings In-Reply-To: <1224734129.35.0.170011642262.issue4185@psf.upfronthosting.co.za> Message-ID: <1228932250.61.0.356805203152.issue4185@psf.upfronthosting.co.za> Guido van Rossum added the comment: Eh? It's just a doc bug now. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:28:30 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2008 18:28:30 +0000 Subject: [issue2734] 2to3 converts long(itude) argument to int In-Reply-To: <1209669660.53.0.857681626906.issue2734@psf.upfronthosting.co.za> Message-ID: <1228933710.59.0.30475661355.issue2734@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: collinwinter -> benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:34:37 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Dec 2008 18:34:37 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228934077.6.0.0722968784844.issue3999@psf.upfronthosting.co.za> STINNER Victor added the comment: fault.py: catch two segfaults in Python and C contexts. Added file: http://bugs.python.org/file12322/fault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:46:53 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2008 18:46:53 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1228934813.28.0.173487786938.issue4617@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +jhylton _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:58:45 2008 From: report at bugs.python.org (John Stracke) Date: Wed, 10 Dec 2008 18:58:45 +0000 Subject: [issue4594] Can't compile with -O3, on ARM, with gcc 3.4.4 In-Reply-To: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za> Message-ID: <1228935524.74.0.52911564552.issue4594@psf.upfronthosting.co.za> John Stracke added the comment: You may be right; I haven't used autoconf before, so I don't know. But I'll give it a shot. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:58:53 2008 From: report at bugs.python.org (Adam Olsen) Date: Wed, 10 Dec 2008 18:58:53 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228935533.78.0.868614886712.issue3999@psf.upfronthosting.co.za> Changes by Adam Olsen : ---------- nosy: +Rhamphoryncus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 20:38:28 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 10 Dec 2008 19:38:28 +0000 Subject: [issue4622] SequenceMatcher bug with long sequences In-Reply-To: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za> Message-ID: <1228937908.09.0.634076919942.issue4622@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Python 2.3.4 and later have this bug. But release 2.1.3 doesn't: Python 2.1.3 (#35, Apr 8 2002, 17:47:50) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import difflib >>> difflib.SequenceMatcher(None, [4] + [5] * 500, [5] * 500).ratio() 0.99900099900099903 >>> difflib.SequenceMatcher(None, [4] + [5] * 200, [5] * 200).ratio() 0.99750623441396513 >>> difflib.SequenceMatcher(None, [4] + [5] * 100, [5] * 100).ratio() 0.99502487562189057 I don't have any 2.2 release to test right now. ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 20:42:22 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 10 Dec 2008 19:42:22 +0000 Subject: [issue4622] SequenceMatcher bug with long sequences In-Reply-To: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za> Message-ID: <1228938142.24.0.583786175513.issue4622@psf.upfronthosting.co.za> Gabriel Genellina added the comment: #2986 may be a duplicate of this; #1528074 is relevant too. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 21:40:53 2008 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 10 Dec 2008 20:40:53 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1228941653.75.0.377827959001.issue4561@psf.upfronthosting.co.za> Changes by Ismail Donmez : ---------- nosy: +cartman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 21:48:39 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Dec 2008 20:48:39 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228942119.68.0.544040698142.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: It's quite possible that I misread the array.array implementation since I only glanced at the code where it fills in the Py_buffer details - I saw the point where it set shape to NULL, but there may have been code later on to fill it in correctly that I missed. Regardless, a coupe of sanity checks on the Py_buffer contents before returning from PyObject_GetBuffer may still be useful to avoid the need for buffer protocol consumers to repeat them all the time (I see this as similar to the type-correctness and range checks we do for things like the index protocol). Antoine, regarding the shapes and strides info for subviews: don't think of it as reallocating or altering the shape of the underlying buffer. Think of it as having separate shape and stride information for the contents of the underlying buffer (i.e. what memoryview gets back from the PyObject_GetBuffer call) and for the view it exposes through indexing and the like (i.e. taking into account the start and stop offsets from the slicing operation). This is what I mean when I say that the current memoryview relies too heavily on the Py_buffer that describes the underlying object - the memoryview needs to maintain its own state *outside* that description. It just so happens that fully describing an arbitrary fragment of the underlying buffer will take a number of the fields that would exist in a separate Py_buffer struct (specifically len, ndim, shape, strides and offsets if we want to cover the non-contiguous and ndim > 1 cases - for the contiguous 1-D cases, we don't needs strides or offsets). Once we consider that aspect, I think it makes the most sense to just maintain 2 Py_buffer instances inside the memoryview - one that describes the underlying buffer, and one that describes the memoryview itself after slicing is taken into account. I also think it is worth considering changing the memoryview to also take start/stop/step arguments in addition to the object to be viewed (initially only supporting step=1, just like slicing, but we should be able to lift that limitation as the implementation matures). The FromBuffer C-level constructor could probably go away at that point. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 21:54:27 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 10 Dec 2008 20:54:27 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228942467.37.0.798137828419.issue4580@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:02:05 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Dec 2008 21:02:05 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228942925.2.0.111181115578.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: Antoine's latest patch looks to me like it will fix the current actual errors in the 1-D case. Something that may also be considered part of this bug is the fact that "m[i] = m[i]" doesn't currently work for itemsize > 1. There is a XXX comment in the memory view implementation as to whether we should require "itemsize == itemsize" in addition to "len == len" when replacing sections of a memoryview. I think the failure of self-assignment shows that we should only be caring about whether or not the total memory size being overwritten matches, rather than the underlying format or size. Alternatively, we could just special case it and say that assignemnt from buffers with itemsize=1 (i.e. raw bytes) is always acceptable, regardless of the itemsize of the buffer underlying the memoryview. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:23:03 2008 From: report at bugs.python.org (Bill Janssen) Date: Wed, 10 Dec 2008 21:23:03 +0000 Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za> Message-ID: <1228944183.83.0.081295744349.issue3890@psf.upfronthosting.co.za> Bill Janssen added the comment: Unrelated? OK, but in fact I fixed this in 3.0 by providing a different internal API to _ssl.c. But you're right, that's an optimization. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:28:08 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 10 Dec 2008 21:28:08 +0000 Subject: [issue887237] Machine integers Message-ID: <1228944488.14.0.360490442291.issue887237@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I wonder if a patch for ctypes like this (which is not yet complete) > could be used to implement this, or MUST it be implemented in C? For the intended purpose of giving access to raw machine arithmetics, I would think a C implementation would be required, but Theller's patch is a good start. > One difficulty with the patch is that the original ctypes code > contained a tp_as_number ... This can be solved by changing the order of bases for c_ classes. See attached. The next step would be to rewrite _NumberMixin in C. C code can be limited to methods operating on known c_ types, say ll_add(x, y) to add two longs and hl_cast(x) to cast short to long with python code taking care of the dispatch. (What's the latest on the multiple dispatch, BTW? ) ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:30:13 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 10 Dec 2008 21:30:13 +0000 Subject: [issue887237] Machine integers Message-ID: <1228944613.45.0.268235806324.issue887237@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file12323/ctypes-numbermixins-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:41:46 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 10 Dec 2008 21:41:46 +0000 Subject: [issue887237] Machine integers Message-ID: <1228945306.9.0.19793576088.issue887237@psf.upfronthosting.co.za> Thomas Heller added the comment: >> One difficulty with the patch is that the original ctypes code >> contained a tp_as_number ... >This can be solved by changing the order of bases for c_ classes. >See attached. Cool! Why didn't I think of that myself? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:28:54 2008 From: report at bugs.python.org (Alex Stapleton) Date: Wed, 10 Dec 2008 22:28:54 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za> Message-ID: <1228948134.38.0.974544409142.issue4610@psf.upfronthosting.co.za> Alex Stapleton added the comment: I agree with loewis that ICU is probably the best way to get this functionality into Python. lemburg, yes it seems like extending those methods would be required at the very least. We would probably also need to support ICUs collators as well I think. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:32:30 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 22:32:30 +0000 Subject: [issue4619] Invalid Behaviour When a Default Argument is a Mutable Object In-Reply-To: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za> Message-ID: <1228948350.13.0.833346950347.issue4619@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't see the need to do anything about this. Python works correctly, and the documentation correctly describes how it works, and how using mutable objects as default values typically doesn't do what the programmer normally expects. In any case, a bug report is not the place to request such a change. At a minimum, a PEP would have to be written (which then likely can't be accepted before Python 4.0). ---------- nosy: +loewis resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:40:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 22:40:22 +0000 Subject: [issue4598] IDLE not opening In-Reply-To: <1228767721.74.0.672735673887.issue4598@psf.upfronthosting.co.za> Message-ID: <1228948822.75.0.160447758755.issue4598@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, closing that as not reproducable, then. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:45:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Dec 2008 22:45:14 +0000 Subject: [issue4185] re module treats raw strings as normal strings In-Reply-To: <1228932250.61.0.356805203152.issue4185@psf.upfronthosting.co.za> Message-ID: <49404677.4090904@v.loewis.de> Martin v. L?wis added the comment: > Eh? It's just a doc bug now. [assuming you are wondering why it is out of scope for 2.5.3] I don't understand the actual issue (and don't have time to find out what it is), so somebody else would have to provide a patch. Since there is no patch, this issue likely misses 2.5.3 (if it is just an error in a doc string, I don't find it particularly necessary to fix it in the bug fix release, either). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:54:24 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 10 Dec 2008 22:54:24 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228949664.43.0.742873506748.issue3999@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 00:06:28 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 10 Dec 2008 23:06:28 +0000 Subject: [issue4597] EvalFrameEx fails to set 'why' for some exceptions In-Reply-To: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za> Message-ID: <1228950388.67.0.722341850249.issue4597@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Reopening: this need to be manually merged into 2.6 and 3.0 maintenance branches. + a NEWS entry is still missing. ---------- nosy: +amaury.forgeotdarc stage: committed/rejected -> commit review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 00:19:49 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 10 Dec 2008 23:19:49 +0000 Subject: [issue4620] Memory leak with datetime used with time.strptime In-Reply-To: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za> Message-ID: <1228951189.68.0.0762517844497.issue4620@psf.upfronthosting.co.za> Gabriel Genellina added the comment: After running for more than 2 hours, I could not see any memory growth with 2.5.2 on WinXP. ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 00:57:39 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 10 Dec 2008 23:57:39 +0000 Subject: [issue4589] 'with' loses ->bool exceptions In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za> Message-ID: <1228953459.52.0.877234451338.issue4589@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Fixed with r67684 (2.5), r67688 (trunk), r67689 (py3k), r67690 (3.0), r67691 (2.6). ---------- resolution: accepted -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:06:05 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 11 Dec 2008 00:06:05 +0000 Subject: [issue1030250] distutils' dry-run wants to create some real build dirs Message-ID: <1228953965.77.0.49994835422.issue1030250@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Committed r67692 (trunk). I don't feel the need to backport: this issue was opened 4 years ago, it is not urgent anymore ;-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:06:17 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 11 Dec 2008 00:06:17 +0000 Subject: [issue1030250] distutils' dry-run wants to create some real build dirs Message-ID: <1228953977.01.0.487973358874.issue1030250@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:13:23 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 11 Dec 2008 00:13:23 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228954403.64.0.552805458514.issue3999@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:50:36 2008 From: report at bugs.python.org (Brian Szuter) Date: Thu, 11 Dec 2008 00:50:36 +0000 Subject: [issue4416] state_reset not called on 'state' before sre_search invoked In-Reply-To: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za> Message-ID: <1228956636.52.0.987436380741.issue4416@psf.upfronthosting.co.za> Brian Szuter added the comment: Examples: /Python-2.5.2/Modules/_sre.c Lines 3289 - 3297 (scanner_search) /Python-2.5.2/Modules/_sre.c Lines 2349 - 2357 (pattern_subx) /Python-2.5.2/Modules/_sre.c Lines 2197 - 2205 (pattern_split) /Python-2.5.2/Modules/_sre.c Lines 2067 - 2075 (pattern_findall) ---------- versions: +Python 2.5.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:50:52 2008 From: report at bugs.python.org (Brian Szuter) Date: Thu, 11 Dec 2008 00:50:52 +0000 Subject: [issue4416] state_reset not called on 'state' before sre_search invoked In-Reply-To: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za> Message-ID: <1228956652.24.0.681438868586.issue4416@psf.upfronthosting.co.za> Changes by Brian Szuter : ---------- versions: +Python 2.7 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:53:31 2008 From: report at bugs.python.org (Brian Szuter) Date: Thu, 11 Dec 2008 00:53:31 +0000 Subject: [issue4416] state_reset not called on 'state' before sre_search invoked In-Reply-To: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za> Message-ID: <1228956811.94.0.212296484936.issue4416@psf.upfronthosting.co.za> Brian Szuter added the comment: This bug was found using a research tool that finds potential neglected condition bugs by examining a code base, deducing rules from the code base, and finding violations of those rules. I have not attempted to demonstrate a problem visible to users from this bug, and so cannot provide a test case demonstrating a problem. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 03:05:21 2008 From: report at bugs.python.org (Louis-Dominique Dubeau) Date: Thu, 11 Dec 2008 02:05:21 +0000 Subject: [issue4216] subprocess.Popen hangs at communicate() when child exits In-Reply-To: <1225151867.64.0.844146967045.issue4216@psf.upfronthosting.co.za> Message-ID: <1228961121.2.0.457144310867.issue4216@psf.upfronthosting.co.za> Louis-Dominique Dubeau added the comment: I'm running python 2.5.2 on Ubuntu 8.10. I believe I've also encountered the problem reported here. The scenario in my case was the following: 1. Python process A uses subprocess.Popen to create another python process (B). Process B is created with stdout=PIPE and stderr=PIPE. Process A communicates with process B using communicate(). 2. Python process B, starts a ssh process (process C) which is invoked to open a new control socket in master mode. Process C is started without pipes so it gets its std{in,out,err} from process B. Process C is going to run for a long time. That is, it will run until a command is sent to the control socket to close the ssh connexion. 3. Process B does not wait for process C to end, so it ends right away. 4. Python process A remains stuck in communicate() until process C (ssh) dies even though process B has ended already. Analysis: The reason for this is that process C (ssh) gets its stdout and stderr from process B. But process C keeps both stdout and stderr opened until it is terminated. So process A does not get an EOF on the pipes it opened for communicating with process B until process C ends. The set of conditions which will trigger the effect is not outlandish. However, it is specific enough that testing by executing "pwd" or "ls -l", or "echo blah" or any other simple command won't trigger it. In my case, I fixed the problem by changing the code of process B to invoke process C with stdout and stderr set to PIPE and close those pipes as soon as process B is satisfied that process C is started properly. In this way, process A does not block. (FYI, process A in my case is the python testing tool nosetests. I use nosetests to test a backup script written in python and that script invokes ssh.) It seems that in general subprocess creators might have two needs: 1. Create a subprocess and communicate with it until there is no more data to be passed to its stdin or data to be read from its std{out,err}. 2. Create a subprocess and communicate with it *only* until *this* process dies. After it is dead, neither stdout nor stderr are of any interest. Currently, need 1 is addressed by communicate() but not need 2. In my scenario above, I was able to work around the problem by modifying process B but there are going to be cases where process B is not modifiable (or at least not easily modifiable). In those cases, process A has to be able to handle it. ---------- nosy: +lemur _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 03:07:04 2008 From: report at bugs.python.org (bianpeng) Date: Thu, 11 Dec 2008 02:07:04 +0000 Subject: [issue4623] IDLE shutdown if I run an edited file contains chinese In-Reply-To: <1228961224.5.0.652279598263.issue4623@psf.upfronthosting.co.za> Message-ID: <1228961224.5.0.652279598263.issue4623@psf.upfronthosting.co.za> New submission from bianpeng : I use IDLE edit an script, if the script contains chinese, IDLE crashed if run the script. I put chinese character in commoent or string, and both get the same result. ---------- components: IDLE files: test.py messages: 77583 nosy: bianpeng severity: normal status: open title: IDLE shutdown if I run an edited file contains chinese type: crash versions: Python 3.0 Added file: http://bugs.python.org/file12324/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 03:11:34 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Thu, 11 Dec 2008 02:11:34 +0000 Subject: [issue4259] Update pydoc URLs In-Reply-To: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za> Message-ID: <1228961494.72.0.824759677299.issue4259@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Committed to 2.5 in rev. 67693. Do I need to 'svnmerge block' this revision to prevent future merges from attempting to apply it to trunk? ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 03:45:15 2008 From: report at bugs.python.org (X Xiao) Date: Thu, 11 Dec 2008 02:45:15 +0000 Subject: [issue4624] Can not import readline on python3.0 (ubuntu 8.04) In-Reply-To: <1228963514.87.0.500617550743.issue4624@psf.upfronthosting.co.za> Message-ID: <1228963514.87.0.500617550743.issue4624@psf.upfronthosting.co.za> New submission from X Xiao : I can "import readline" just fine on AMD64 ubuntu 8.04 under python3.0, however on 32-bit ubuntu 8.04 I could not "import readline" for python3.0. It says "import readline ImportError: No module named readline". I made sure both ubuntu machines have readline installed correctly, python2.x runs well and can import readline without any issues. ---------- components: Installation messages: 77585 nosy: xxiao severity: normal status: open title: Can not import readline on python3.0 (ubuntu 8.04) type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 03:47:50 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 02:47:50 +0000 Subject: [issue4624] Can not import readline on python3.0 (ubuntu 8.04) In-Reply-To: <1228963514.87.0.500617550743.issue4624@psf.upfronthosting.co.za> Message-ID: <1228963670.65.0.0482344146557.issue4624@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Did you build Python yourself? If so, can you paste the last lines of the build process like this: Failed to find the necessary bits to build these modules: bsddb185 gdbm linuxaudiodev ossaudiodev spwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. running build_scripts ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 03:59:02 2008 From: report at bugs.python.org (X Xiao) Date: Thu, 11 Dec 2008 02:59:02 +0000 Subject: [issue4624] Can not import readline on python3.0 (ubuntu 8.04) In-Reply-To: <1228963514.87.0.500617550743.issue4624@psf.upfronthosting.co.za> Message-ID: <1228964342.75.0.507728737333.issue4624@psf.upfronthosting.co.za> X Xiao added the comment: I just rebuild it again, it went away. not sure what I did wrong at first try. The last few lines during compilation are: INFO: Can't locate Tcl/Tk libs and/or headers Failed to find the necessary bits to build these modules: _dbm _sqlite3 _tkinter To find the necessary bits, look in setup.py in detect_modules() for the module's name. Looks like I need install python-sqlite etc. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 03:59:43 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 02:59:43 +0000 Subject: [issue4624] Can not import readline on python3.0 (ubuntu 8.04) In-Reply-To: <1228963514.87.0.500617550743.issue4624@psf.upfronthosting.co.za> Message-ID: <1228964383.5.0.854268880173.issue4624@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 04:30:22 2008 From: report at bugs.python.org (Sophia K. Cheng) Date: Thu, 11 Dec 2008 03:30:22 +0000 Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za> Message-ID: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za> New submission from Sophia K. Cheng : Hello, I was able to run IDLE once or twice on my laptop. Then I downloaded kiki and tried to run it but had forgotten to install wxPython. After that, IDLE no longer opens although the command prompt does still work. I get the following error: C:\Python25>python.exe Lib\idlelib\idle.py Traceback (most recent call last): File "Lib\idlelib\idle.py", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1404, in main shell = flist.open_shell() File "C:\Python25\lib\idlelib\PyShell.py", line 275, in open_shell self.pyshell = PyShell(self) File "C:\Python25\lib\idlelib\PyShell.py", line 813, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Python25\lib\idlelib\OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "C:\Python25\lib\idlelib\EditorWindow.py", line 248, in __init__ self.update_recent_files_list() File "C:\Python25\lib\idlelib\EditorWindow.py", line 715, in update_recent_fil es_list rf_file = open(self.recent_files_path, 'w') IOError: [Errno 13] Permission denied: 'C:\\Documents and Settings\\skcheng\\.id lerc\\recent-files.lst' I've tried uninstalling and reinstalling several times 2.5 and also 2.6. When I look at the folder .idlerc in windows explorer, I get an error each time I click on it that access is denied, even though I am running as administrator on my laptop. I have tried uninstalling Python and deleting the .idlerc folder. I have also tried manually unchecking the read-only property for the folder. I have a Lenovo T400 that is built for Windows Vista, but am running Windows XP. Thank you. ---------- components: IDLE messages: 77588 nosy: skcheng severity: normal status: open title: IDLE won't open anymore, .idlerc unaccessible versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 04:38:42 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 11 Dec 2008 03:38:42 +0000 Subject: [issue3999] Real segmentation fault handler In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za> Message-ID: <1228966722.04.0.594532852284.issue3999@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 05:21:46 2008 From: report at bugs.python.org (Facundo Batista) Date: Thu, 11 Dec 2008 04:21:46 +0000 Subject: [issue4084] Decimal.max(NaN, x) gives incorrect results when x is finite and long In-Reply-To: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za> Message-ID: <1228969306.74.0.714279626398.issue4084@psf.upfronthosting.co.za> Facundo Batista added the comment: Commited in trunk and Py3, thanks Mark! Please, could you commit it in 2.5? The only change I've made in the patch is adding the issue number to Misc/NEWS, the rest is ok. After that, just close this. Thanks again! ---------- versions: -Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:19:17 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 11 Dec 2008 06:19:17 +0000 Subject: [issue4626] compile() doesn't ignore the source encoding when a string is passed in In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za> Message-ID: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za> New submission from Brett Cannon : When compile() is called with a string it is a reasonable assumption that it has already been decoded. But this is not in fact the case and leads to errors when trying to use non-ASCII identifiers:: >>> source = "# coding=latin-1\n\u00c6 = '\u00c6'" >>> compile(source, '', 'exec') Traceback (most recent call last): File "", line 1, in File "", line 2 ?? = '??' ^ SyntaxError: invalid character in identifier >>> compile(source.encode('latin-1'), '', 'exec') at 0x389cc8, file "", line 2> ---------- components: Interpreter Core messages: 77590 nosy: brett.cannon severity: normal stage: needs patch status: open title: compile() doesn't ignore the source encoding when a string is passed in type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:27:00 2008 From: report at bugs.python.org (Carl Johnson) Date: Thu, 11 Dec 2008 06:27:00 +0000 Subject: [issue4627] Add Mac OS X Disk Images to Python.org homepage In-Reply-To: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za> Message-ID: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za> New submission from Carl Johnson : As recently as Python 2.6.0's release, Python.org had a link to download a disk image with a special newb-friendly installer for OS X. See http://www.python.org/download/releases/2.6/ Now, it's gone in Python 2.6.1, and it was never there for Python 3.0. Which is a pain, because it's really hard to get "readlines" to install just using config/make/install. So, whoever is in charge of making that disk image should make it again. ---------- components: Macintosh messages: 77591 nosy: carlj severity: normal status: open title: Add Mac OS X Disk Images to Python.org homepage type: compile error versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:38:42 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Dec 2008 06:38:42 +0000 Subject: [issue4259] Update pydoc URLs In-Reply-To: <1228961494.72.0.824759677299.issue4259@psf.upfronthosting.co.za> Message-ID: <4940B56F.9000305@v.loewis.de> Martin v. L?wis added the comment: > Committed to 2.5 in rev. 67693. > > Do I need to 'svnmerge block' this revision to prevent > future merges from attempting to apply it to trunk? I don't fully understand the question (did you wonder whether to invoke the block on the trunk, or on the branch?). I think this answer is "no": we neither merge from the trunk to the 2.5 branch, nor vice versa, using svnmerge. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:39:49 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Thu, 11 Dec 2008 06:39:49 +0000 Subject: [issue4597] EvalFrameEx fails to set 'why' for some exceptions In-Reply-To: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za> Message-ID: <1228977589.99.0.587485039085.issue4597@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Added NEWS in r67685; ported to 2.5 branch in r67687; to 2.6 branch in r67696; to 3.1 branch in r67697; and to 3.0 branch in r67698. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:41:21 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Dec 2008 06:41:21 +0000 Subject: [issue4084] Decimal.max(NaN, x) gives incorrect results when x is finite and long In-Reply-To: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za> Message-ID: <1228977681.25.0.40939089422.issue4084@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Mark, if you want to backport this, please go ahead. If want me to, assign to me. ---------- assignee: facundobatista -> marketdickinson priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:43:40 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Dec 2008 06:43:40 +0000 Subject: [issue4627] Add Mac OS X Disk Images to Python.org homepage In-Reply-To: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za> Message-ID: <1228977820.56.0.849865398057.issue4627@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Unfortunately, nobody is "in charge" of making disk images (this is a volunteer project entirely), so none might get made. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:54:07 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 11 Dec 2008 06:54:07 +0000 Subject: [issue4628] No universal newline support for compile() when using bytes In-Reply-To: <1228978447.23.0.301216613627.issue4628@psf.upfronthosting.co.za> Message-ID: <1228978447.23.0.301216613627.issue4628@psf.upfronthosting.co.za> New submission from Brett Cannon : Passing in bytes to compile() works well for letting the parser handle the decoding of a file when an encoding is specified, but it doesn't take care of universal newlines:: >>> source = b'a = 1\r\nb = 2\r\n' >>> compile(source, '', 'exec') Traceback (most recent call last): File "", line 1, in File "", line 1 a = 1 ^ SyntaxError: invalid syntax ---------- components: Interpreter Core messages: 77596 nosy: brett.cannon severity: normal stage: needs patch status: open title: No universal newline support for compile() when using bytes type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:54:18 2008 From: report at bugs.python.org (Wang Chun) Date: Thu, 11 Dec 2008 06:54:18 +0000 Subject: [issue4629] getopt should not accept no_argument that ends with '=' In-Reply-To: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za> Message-ID: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za> New submission from Wang Chun : Consider the following program tmp.py: import sys, getopt print(getopt.getopt(sys.argv[1:], '', ['help'])) The program accept "--help" without a value: python helloworld.py --help But if someone invoke the program like: python helloworld.py --help= Python should raise an error. "--help=" is not considered as no_argument in libc's getopt implementation (tested on Mac OS X Leopard): #include static struct option longopts[] = { { "help", no_argument, NULL, "h" }, }; #include static struct option longopts[] = { { "help", no_argument, NULL, 'h' }, }; int main(int argc, char **argv) { while (getopt_long(argc, argv, "h", longopts, NULL) != -1); return 0; } macbook:~/tmp$ gcc -o tmp tmp.c macbook:~/tmp$ ./tmp --help= tmp: option `--help' doesn't allow an argument macbook:~/tmp$ ---------- components: Library (Lib) messages: 77597 nosy: wangchun severity: normal status: open title: getopt should not accept no_argument that ends with '=' type: behavior versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 08:12:45 2008 From: report at bugs.python.org (Wang Chun) Date: Thu, 11 Dec 2008 07:12:45 +0000 Subject: [issue4629] getopt should not accept no_argument that ends with '=' In-Reply-To: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za> Message-ID: <1228979565.34.0.447005356233.issue4629@psf.upfronthosting.co.za> Changes by Wang Chun : ---------- keywords: +patch Added file: http://bugs.python.org/file12325/getopt.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 09:05:54 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 11 Dec 2008 08:05:54 +0000 Subject: [issue4630] IDLE no longer respects .Xdefaults insertOffTime In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za> Message-ID: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za> New submission from Mark Summerfield : IDLE's cursor blinks with Python 3.0 on Linux. But it shouldn't (and doesn't for prior versions) because in my .Xdefaults file I have the line: *insertOffTime: 0 Now I have to manually edit idlelib/EditorWindow.py to stop the cursor from blinking. (I also have to do this on Windows because IDLE ignores the blink rate set in the control panel.) I am one of a minority of people who cannot work with blinking cursors. I hope that at the least IDLE will get an option to switch it off. ---------- components: IDLE messages: 77598 nosy: mark severity: normal status: open title: IDLE no longer respects .Xdefaults insertOffTime versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 10:03:35 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 11 Dec 2008 09:03:35 +0000 Subject: [issue4416] state_reset not called on 'state' before sre_search invoked In-Reply-To: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za> Message-ID: <1228986215.03.0.976685285265.issue4416@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: There is no issue: in pattern_search, state_init is called before sre_search is invoked. And state_init contains all the operations performed by state_reset. The invariant here is that each call to sre_search must be preceded by a call to state_reset *or* state_init. I don't know whether your tool can detect this. ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 10:10:56 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 09:10:56 +0000 Subject: [issue4084] Decimal.max(NaN, x) gives incorrect results when x is finite and long In-Reply-To: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za> Message-ID: <1228986656.91.0.672256258776.issue4084@psf.upfronthosting.co.za> Mark Dickinson added the comment: Committed, r67699. Thanks! Leaving open because I still need to merge this to the 3.0 and 2.6 maintenance branches. ---------- priority: release blocker -> normal versions: +Python 2.6, Python 3.0 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 10:25:21 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 09:25:21 +0000 Subject: [issue4084] Decimal.max(NaN, x) gives incorrect results when x is finite and long In-Reply-To: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za> Message-ID: <1228987521.29.0.794943398035.issue4084@psf.upfronthosting.co.za> Mark Dickinson added the comment: Merged to 2.6 and 3.0 maintenance branches (r67700, r67701). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 11:52:43 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Thu, 11 Dec 2008 10:52:43 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <1228787916.58.0.49206821132.issue4602@psf.upfronthosting.co.za> Message-ID: <20081211105236.GA26241@chistera.yi.org> Adeodato Sim? added the comment: > Thanks for the report! Fixed in r67674. I'm afraid I'm unfamiliar with Python development procedures: that commit was committed to /sandox, is that expected? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 12:23:02 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Thu, 11 Dec 2008 11:23:02 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> New submission from Adeodato Sim? : This is very odd, but it was reproduced by people in #python as well. Compare, in python 2.5: >>> urllib.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readline() 'From mechanix at lucretia.debian.net Tue Dec 11 11:32:47 2001\n' To the equivalent in python 3.0: >>> urllib.request.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readline() b'f65\r\n' ---------- components: Library (Lib) messages: 77603 nosy: dato severity: normal status: open title: urlopen returns extra, spurious bytes versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:01:57 2008 From: report at bugs.python.org (Thomas Heller) Date: Thu, 11 Dec 2008 12:01:57 +0000 Subject: [issue4632] Wrong fix for range(42)[::-1] In-Reply-To: <1228996917.04.0.00625258581856.issue4632@psf.upfronthosting.co.za> Message-ID: <1228996917.04.0.00625258581856.issue4632@psf.upfronthosting.co.za> New submission from Thomas Heller : The 2to3 fixer translates this code: range(42)[::-1] into this one: list(range(42)[::-1] which throws an error when run with Python 3: Traceback (most recent call last): File "test.py", line 1, in print(list(range(42)[::-1])) TypeError: sequence index must be integer, not 'slice' ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 77604 nosy: theller severity: normal status: open title: Wrong fix for range(42)[::-1] _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:12:46 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 11 Dec 2008 12:12:46 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1228997566.37.0.210032462425.issue4631@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I don't reproduce the problem: >>> urllib.request.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readline() b'From mechanix at lucretia.debian.net Tue Dec 11 11:32:47 2001\n' I connect through a http proxy. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:43:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Dec 2008 12:43:05 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1228999385.71.0.684707722552.issue4580@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Antoine, regarding the shapes and strides info for subviews: don't think > of it as reallocating or altering the shape of the underlying buffer. > Think of it as having separate shape and stride information for the > contents of the underlying buffer I'm trying to be practical. If the additional shape/strides storage is in Py_buffer, it can benefit anyone wanting to create a subview or doint to do something else with shape and strides. If the storage is in memoryview, it only benefits memoryview. > I also think it is worth considering changing the memoryview to also > take start/stop/step arguments in addition to the object to be viewed > (initially only supporting step=1, just like slicing, but we should be > able to lift that limitation as the implementation matures). The > FromBuffer C-level constructor could probably go away at that point. Could you open a separate bug for this? I agree simplifications are welcome. As for the additional arguments, if we have proper slicing support I'm not sure they are really useful (at the Python level at least). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:59:08 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 12:59:08 +0000 Subject: [issue4627] Add Mac OS X Disk Images to Python.org homepage In-Reply-To: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za> Message-ID: <1229000348.66.0.620661132955.issue4627@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I have built a Mac Installer (and tested). I'm not sure how to upload it, though. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:00:28 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 13:00:28 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <20081211105236.GA26241@chistera.yi.org> Message-ID: <1afaf6160812110458w7b8ea8ebne89c9a1bceb61a42@mail.gmail.com> Benjamin Peterson added the comment: On Thu, Dec 11, 2008 at 4:52 AM, Adeodato Sim? wrote: > > Adeodato Sim? added the comment: > >> Thanks for the report! Fixed in r67674. > > I'm afraid I'm unfamiliar with Python development procedures: that > commit was committed to /sandox, is that expected? Yes, it will be merged into the trunk eventually. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:03:26 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Thu, 11 Dec 2008 13:03:26 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <1afaf6160812110458w7b8ea8ebne89c9a1bceb61a42@mail.gmail.com> Message-ID: <20081211130323.GA30460@chistera.yi.org> Adeodato Sim? added the comment: > Yes, it will be merged into the trunk eventually. Great, thank you and sorry for the noise. Also, is this fix elegible for the 3.0 branch? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:06:33 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 13:06:33 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <20081211130323.GA30460@chistera.yi.org> Message-ID: <1afaf6160812110504k6d48def1u334f213eb15d434c@mail.gmail.com> Benjamin Peterson added the comment: On Thu, Dec 11, 2008 at 7:03 AM, Adeodato Sim? wrote: > > Adeodato Sim? added the comment: > >> Yes, it will be merged into the trunk eventually. > > Great, thank you and sorry for the noise. Also, is this fix elegible for > the 3.0 branch? Yes, it will find its way into 2.6.2, 3.0.1, and 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:13:23 2008 From: report at bugs.python.org (Daniel Diniz) Date: Thu, 11 Dec 2008 13:13:23 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229001203.85.0.593117677407.issue4631@psf.upfronthosting.co.za> Daniel Diniz added the comment: Confirmed: Python 3.1a0 (py3k:67702, Dec 11 2008, 11:09:14) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib.request >>> urllib.request.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readlines() [b'f65\r\n', b'From mechanix at lucretia.debian.net Tue Dec 11 11:32:47 2001\n', ... Perhaps it's related to the \r at read boundaries bug? ---------- nosy: +ajaksu2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:53:58 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 11 Dec 2008 13:53:58 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229003638.88.0.787208793129.issue4631@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: The "f65" is the chunk length for the first chunk returned when requesting that URL. A proxy could easily hide this by switching to a different transfer encoding. ---------- nosy: +exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:43:34 2008 From: report at bugs.python.org (Armin Rigo) Date: Thu, 11 Dec 2008 14:43:34 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1229006614.29.0.182429360811.issue4228@psf.upfronthosting.co.za> Armin Rigo added the comment: FWIW, struct.pack("I", "whatever") produces "\x00\x00\x00\x00" too. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:46:08 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 11 Dec 2008 14:46:08 +0000 Subject: [issue4620] Memory leak with datetime used with time.strptime In-Reply-To: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za> Message-ID: <1229006768.12.0.746544336792.issue4620@psf.upfronthosting.co.za> Skip Montanaro added the comment: A number of people on a number of platforms and versions can't reproduce this. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 16:20:58 2008 From: report at bugs.python.org (Armin Rigo) Date: Thu, 11 Dec 2008 15:20:58 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1229008858.39.0.96877867235.issue4228@psf.upfronthosting.co.za> Armin Rigo added the comment: Attached struct-2.5-fix.diff. The tests still pass (both 32- and 64-bits). ---------- keywords: +patch Added file: http://bugs.python.org/file12326/struct-2.5-fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 16:28:44 2008 From: report at bugs.python.org (Stuart Woodward) Date: Thu, 11 Dec 2008 15:28:44 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1229009324.76.0.788487465864.issue2173@psf.upfronthosting.co.za> Stuart Woodward added the comment: I'm running on Mac OS X. I applied the patch issue2173.patch and it solved the "make: *** [sharedmods] Error 1" problem. A cursory test of /usr/local/bin/python3.0 was successful. ---------- nosy: +stuartcw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 16:31:17 2008 From: report at bugs.python.org (Yavuz Onder) Date: Thu, 11 Dec 2008 15:31:17 +0000 Subject: [issue4633] file.tell() gives wrong result In-Reply-To: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za> Message-ID: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za> New submission from Yavuz Onder : I find that file.tell returns not the byte offset of the next byte, but possibly the byte offset of the next block to be read. I find it always to be a multiple of 1024. Following is a demo of the bug. where I read a few lines into a text file, step back by the length of the last read line, read again, and do not find the same data. What is returned is the tail part of a line way down in the file. I woeked around by keeping track of the file pointer, and seek worked fine. tell() is at fault. ----------demonstration on a text file Python 2.5.1 (r251:54863, Nov 14 2007, 16:00:54) [GCC 3.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> jf=open('junk','r') >>> line=jf.next() >>> line '\n' >>> line=jf.next() >>> line 'See COPYING file in the same directory as this one for license.\n' >>> line=jf.next() >>> line '\n' >>> line=jf.next() >>> line 'Thank you for trying this utility. I had great fun putting it\n' >>> line=jf.next() >>> line 'together, and I hope users will find it useful.\n' >>> jf.seek(len(line),1) >>> line=jf.next() >>> line 'gle says Maps will not work without it. file:// URLs are \n' ---------- components: None messages: 77617 nosy: yavuz164 severity: normal status: open title: file.tell() gives wrong result versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 16:47:22 2008 From: report at bugs.python.org (Lino Mastrodomenico) Date: Thu, 11 Dec 2008 15:47:22 +0000 Subject: [issue4634] 2to3 should fix "import HTMLParser" In-Reply-To: <1229010441.99.0.194542520583.issue4634@psf.upfronthosting.co.za> Message-ID: <1229010441.99.0.194542520583.issue4634@psf.upfronthosting.co.za> New submission from Lino Mastrodomenico : This should be easy: 2to3 must convert "import HTMLParser" to "import html.parser". ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 77618 nosy: mastrodomenico severity: normal status: open title: 2to3 should fix "import HTMLParser" type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 16:52:53 2008 From: report at bugs.python.org (Tim Gordon) Date: Thu, 11 Dec 2008 15:52:53 +0000 Subject: [issue4633] file.tell() gives wrong result In-Reply-To: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za> Message-ID: <4941374F.9060105@aleph17.co.uk> Tim Gordon added the comment: See the documentation for file.next (http://docs.python.org/library/stdtypes.html#file.next). As you can see, file.next uses a buffer which will mess with the result of other methods, such as file.tell. ---------- nosy: +QuantumTim _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 17:02:15 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 16:02:15 +0000 Subject: [issue4633] file.tell() gives wrong result In-Reply-To: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za> Message-ID: <1229011335.28.0.118801575247.issue4633@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 17:10:57 2008 From: report at bugs.python.org (Yavuz Onder) Date: Thu, 11 Dec 2008 16:10:57 +0000 Subject: [issue4633] file.tell() gives wrong result In-Reply-To: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za> Message-ID: <1229011857.07.0.994932613207.issue4633@psf.upfronthosting.co.za> Yavuz Onder added the comment: O.K. But, is there a way to backtrack to the beginning of the last read line, without explicitly implementing accounting of the real file pointer in the code, and doing "seek(,0)"? The documentation you pointed to implies that, in "for name in file:" loop a clean backtracking is not possible. Am I missing something? Thanks. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 17:13:53 2008 From: report at bugs.python.org (Tim Gordon) Date: Thu, 11 Dec 2008 16:13:53 +0000 Subject: [issue4633] file.tell() gives wrong result In-Reply-To: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za> Message-ID: <1229012033.62.0.162460848481.issue4633@psf.upfronthosting.co.za> Tim Gordon added the comment: Try using the readline method instead of next. I don't think that applies the same buffering. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 18:25:49 2008 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 11 Dec 2008 17:25:49 +0000 Subject: [issue4635] no reference for optparse methods In-Reply-To: <1229016349.77.0.360903812636.issue4635@psf.upfronthosting.co.za> Message-ID: <1229016349.77.0.360903812636.issue4635@psf.upfronthosting.co.za> New submission from anatoly techtonik : optparse documentation misses reference for at least these three methods: print_help() print_usage() print_version() ---------- assignee: georg.brandl components: Documentation messages: 77622 nosy: georg.brandl, techtonik severity: normal status: open title: no reference for optparse methods versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 19:09:36 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 18:09:36 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1229018976.23.0.142580004517.issue2173@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks, Stuart! I've committed the fix in r67703 and r67704, so it should appear in 3.0.1. This should fix the silent build failure, and the zero-output interpreter. The behaviour is still not ideal: a bad LC_CTYPE setting causes sys.stdout and sys.stdin to have their encodings set to 'ascii'. 'UTF-8' would probably be a better guess, on OS X. But this is a lesser problem. To fix it, we should try to understand why nl_langinfo is returning an empty string in the first place. But maybe only Apple knows the answer to that one. :) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 19:11:30 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 11 Dec 2008 18:11:30 +0000 Subject: [issue4634] 2to3 should fix "import HTMLParser" In-Reply-To: <1229010441.99.0.194542520583.issue4634@psf.upfronthosting.co.za> Message-ID: <1229019090.21.0.772082656504.issue4634@psf.upfronthosting.co.za> David W. Lambert added the comment: It is hard. Although you know what you mean, 2to3 has no way to know for instance, that you never run your program with working directory containing file HTMLParser.py. 2to3 could offer a suggestion rather than reporting no change required. This issue is common. ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 19:13:31 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 18:13:31 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1229019211.71.0.0148674092363.issue2173@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:04:21 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 19:04:21 +0000 Subject: [issue4632] Wrong fix for range(42)[::-1] In-Reply-To: <1228996917.04.0.00625258581856.issue4632@psf.upfronthosting.co.za> Message-ID: <1229022261.81.0.824610394916.issue4632@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67705. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:14:03 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 19:14:03 +0000 Subject: [issue3167] math test fails on Solaris 10 In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za> Message-ID: <1229022843.76.0.332017159059.issue3167@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file10764/issue3167.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:18:21 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2008 19:18:21 +0000 Subject: [issue4634] 2to3 should fix "import HTMLParser" In-Reply-To: <1229010441.99.0.194542520583.issue4634@psf.upfronthosting.co.za> Message-ID: <1229023101.62.0.290701472854.issue4634@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We do have a fixer that changes imports from std reorg. I added HTMLParser and htmlentitydefs in r67706. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:32:16 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 19:32:16 +0000 Subject: [issue3167] math test fails on Solaris 10 In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za> Message-ID: <1229023936.66.0.270206160272.issue3167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks, both! Fixed in the trunk in r67707. I'll wait to be sure that the buildbots are happy, then merge to 2.6, 3.0, 3.1. ---------- versions: +Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:54:45 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 19:54:45 +0000 Subject: [issue2819] Full precision summation In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za> Message-ID: <1229025285.59.0.495836327193.issue2819@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing this. Let's stick with what we have. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:06:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Dec 2008 20:06:14 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1229025974.77.0.90810205255.issue4228@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:37:21 2008 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 11 Dec 2008 20:37:21 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228999385.71.0.684707722552.issue4580@psf.upfronthosting.co.za> Message-ID: <494179F2.3070507@gmail.com> Nick Coghlan added the comment: > I'm trying to be practical. If the additional shape/strides storage is > in Py_buffer, it can benefit anyone wanting to create a subview or doint > to do something else with shape and strides. If the storage is in > memoryview, it only benefits memoryview. I'm not sure I follow that - no matter where they're stored, doing PyObject_GetBuffer on the memoryview should use the *memoryview's* shape/stride information rather than that of the underlying object. That's how getting this right in memoryview can help third parties: to get a subview of something else, take a memoryview of it, slice the memoryview, then get the Py_buffer information from the memoryview slice. Hence my opinion that it makes sense to have an easy API (at least at the C level) to create a memoryview given both an original object and start/stop/step information - not only will it be useful internally for the implementation of proper multi-dimensional slicing support in memoryview itself, but it will also be convenient for third parties trying to use or support the PEP 3118 protocol. I agree wholeheartedly with your complaints about Py_buffer and the PyObject_GetBuffer protocol being somewhat awkward to use. However, I don't agree that it is a significant problem. One focus for the underlying protocol design was on being fairly minimalist while still providing sufficient expressiveness to cover all of the use cases identified by the number crunching crowd - as Greg pointed out on python-dev, it's best to think of Py_buffer's role in the protocol as merely a location to store a fairly large set of output variables describing the internal storage of the object supplying the data buffer. The convenience layer that you're after (the one that will make the PEP 3118 API simpler to use by supporting normal PyObject semantics and easy creation of subviews) should actually *be* memoryview, but the implementation isn't there yet. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:12:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 21:12:15 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229029935.49.0.170376167392.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Victor, Thanks for the updated patch. I think you need to do a PyErr_Clear after the 'return PyLong_FromSize_t' line. To be safe, you should probably check the exception type first, and either do a PyErr_Clear and continue if it's an OverflowError, or just return NULL if it's some other exception. It's true that _PyLong_NumBits can't raise anything other than OverflowError at the moment, but you never know when that might change. :) I'm also getting a 'malformed table' warning when building the documentation. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:16:08 2008 From: report at bugs.python.org (Thomas Heller) Date: Thu, 11 Dec 2008 21:16:08 +0000 Subject: [issue4636] bdist_wininst installer with install script raises exception In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za> Message-ID: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za> New submission from Thomas Heller : Running a bdist_wininst installer that contains a install script, with python 3, raises an exception. This is displayed in the gui: ImportError: No module named __builtin__ *** run_installscript: internal error 0xFFFFFFFF *** This is probably because the bdist_wininst installer stubs (in the Lib/distutils/command subdirectory) have not been recompiled after changing the sources. ---------- components: Distutils messages: 77631 nosy: theller severity: normal status: open title: bdist_wininst installer with install script raises exception versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:22:14 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 21:22:14 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229030534.46.0.328089933083.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Alternatively, you could just ignore _PyLong_NumBits entirely and put the whole calculation into long_numbits. You're already halfway there with the calculation of msd_bits anyway, and I suspect the code will look cleaner (and run faster) that way. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:05:21 2008 From: report at bugs.python.org (Michael Hoffman) Date: Thu, 11 Dec 2008 22:05:21 +0000 Subject: [issue2155] optparse.OptionGroup with_statement context handling In-Reply-To: <1203608881.22.0.564217354476.issue2155@psf.upfronthosting.co.za> Message-ID: <1229033121.96.0.947865462111.issue2155@psf.upfronthosting.co.za> Michael Hoffman added the comment: Is there anything I can do to get this feature request considered earlier? I can generate a real patch, but I figured that wouldn't necessary for something so simple. This has the advantage that it can probably be cut/pasted into any version of the code. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:06:18 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 22:06:18 +0000 Subject: [issue3167] math test fails on Solaris 10 In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za> Message-ID: <1229033178.75.0.174788018082.issue3167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Buildbots seem content. Merged to 2.6, 3.0, 3.1. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:08:16 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2008 22:08:16 +0000 Subject: [issue3682] test_math: math.log(-ninf) fails to raise exception on OpenBSD In-Reply-To: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za> Message-ID: <1229033296.88.0.225022905166.issue3682@psf.upfronthosting.co.za> Mark Dickinson added the comment: I've committed the issue 3167 fix in revisions r67707 to r67710. I'm fairly sure that this patch should resolve this issue. (Let me know if it doesn't.) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:05:41 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:05:41 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229036741.24.0.929295640586.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, you're right Mark: PyErr_Clear() is needed! New patch: - don't catch error different than PyExc_OverflowError in long_numbits() - clear error in long_numbits() - fix doc indentation About the indentation: i'm using >>svndiff='svn diff --diff-cmd="/usr/bin/diff" -x "-ub"'<< instead of svn diff because my editor removes trailing spaces. I prefer to keep the "fast path" (use _PyLong_NumBits) as *you* proposed in another message: Message75767. Added file: http://bugs.python.org/file12327/numbits-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:05:46 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:05:46 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229036746.15.0.104701464695.issue3439@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file12302/numbits-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:07:37 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:07:37 +0000 Subject: [issue3632] use string_print() in gdb In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za> Message-ID: <1229036857.65.0.773244827887.issue3632@psf.upfronthosting.co.za> STINNER Victor added the comment: Can anyone apply this patch? Or explain me why it can not be applied? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:08:53 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:08:53 +0000 Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za> Message-ID: <1229036933.55.0.563992815322.issue3638@psf.upfronthosting.co.za> STINNER Victor added the comment: gpolo agree to remove it. If no one is opposed for this change, can someone apply the patch? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:09:25 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:09:25 +0000 Subject: [issue3880] _tkinter._flatten() doesn't check PySequence_Size() error code In-Reply-To: <1221572716.31.0.755070088085.issue3880@psf.upfronthosting.co.za> Message-ID: <1229036965.24.0.0648416461492.issue3880@psf.upfronthosting.co.za> STINNER Victor added the comment: gpolo reviewed the patch. So can anyone apply the patch? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:13:52 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:13:52 +0000 Subject: [issue3952] _lsprof: clear() should call flush_unmatched() In-Reply-To: <1222219328.76.0.602702790572.issue3952@psf.upfronthosting.co.za> Message-ID: <1229037232.98.0.476031907709.issue3952@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm unable to reproduce my issue with Python trunk, so close it. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:16:06 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:16:06 +0000 Subject: [issue3954] _hotshot: invalid error control in logreader() In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za> Message-ID: <1229037366.49.0.106306786701.issue3954@psf.upfronthosting.co.za> STINNER Victor added the comment: > Regardless of the smiley, I certainly wouldn't object if you > requested permissions on python-dev... I still don't have an account and the issue is still open. 2.6(.1) and 3.0 are released. The patch has been reviewed by amaury.forgeotdarc, so can the patch be applied? The issue is still valid with python trunk: $ ./python Python 2.7a0 (trunk:67710M, Dec 11 2008, 23:57:18) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 >>> import _hotshot, gc >>> _hotshot.logreader(".") <_hotshot.LogReaderType object at 0xb7d936e0> >>> gc.collect() Exception EOFError: 'end of file with incomplete profile record' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Abandon (core dumped) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:21:00 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:21:00 +0000 Subject: [issue4021] tokenize.detect_encoding(): raise SyntaxError on codecs.lookup() error In-Reply-To: <1222988433.37.0.412294241613.issue4021@psf.upfronthosting.co.za> Message-ID: <1229037660.86.0.0894363591893.issue4021@psf.upfronthosting.co.za> STINNER Victor added the comment: New version of the patch: - remove utf8_bom (was already replaced by codecs.BOM_UTF8) - include the regression test from amaury.forgeotdarc Can anyone review the new patch (which is very similar to the first one) and commit it? Added file: http://bugs.python.org/file12328/tokenize_detect_encoding-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:21:57 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:21:57 +0000 Subject: [issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open() In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za> Message-ID: <1229037717.38.0.969190628528.issue4016@psf.upfronthosting.co.za> STINNER Victor added the comment: "This patch looks good." ok and then? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:29:13 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:29:13 +0000 Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za> Message-ID: <1229038153.64.0.591750757138.issue4294@psf.upfronthosting.co.za> STINNER Victor added the comment: We have now a benchmark tool (attached file "bench_int.py"), many patches to try, and 3.0 is released. Anyone interrested to work on it? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:34:26 2008 From: report at bugs.python.org (Retro) Date: Thu, 11 Dec 2008 23:34:26 +0000 Subject: [issue4637] Binary floating point and decimal floating point arithmetic In-Reply-To: <1229038466.07.0.748042686463.issue4637@psf.upfronthosting.co.za> Message-ID: <1229038466.07.0.748042686463.issue4637@psf.upfronthosting.co.za> New submission from Retro : Please consider of making the default floating point arithmetic in Python 3.x be decimal floating point arithmetic. ---------- components: Interpreter Core messages: 77645 nosy: Retro, gvanrossum severity: normal status: open title: Binary floating point and decimal floating point arithmetic type: feature request versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:36:04 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2008 23:36:04 +0000 Subject: [issue2706] datetime: define division timedelta/timedelta In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za> Message-ID: <1229038564.25.0.548338371367.issue2706@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm finally opposed to datetime.totimedelta() => float, I prefer .totimedelta() => (second, microsecond) which means (int,int). But I like timedelta/timedelta => float, eg. to compute a progression percent. Anyone interested by my last patch (implement timedelta/timedelta and divmod(timedelta, timedelta)? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:36:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Dec 2008 23:36:36 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <494179F2.3070507@gmail.com> Message-ID: <1229038597.15796.9.camel@localhost> Antoine Pitrou added the comment: > > I'm trying to be practical. If the additional shape/strides storage is > > in Py_buffer, it can benefit anyone wanting to create a subview or doint > > to do something else with shape and strides. If the storage is in > > memoryview, it only benefits memoryview. > > I'm not sure I follow that Not everyone wanting to do something with a Py_buffer constructs a memoryview, so it sounds sensible to give Py_buffer users as much power as memoryview users. Otherwise, let's kill Py_buffer as an independent struct, keep memoryview as the only building block of the buffer API... something which I totally agree with (but apparently others don't). > it's best to think of Py_buffer's role in the protocol as > merely a location to store a fairly large set of output variables > describing the internal storage of the object supplying the data buffer. And I think I've made my point that it's a broken design principle, leading to two types instead of one. May I remind you that: Simple is better than complex. Complex is better than complicated. ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:39:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Dec 2008 23:39:52 +0000 Subject: [issue4637] Binary floating point and decimal floating point arithmetic In-Reply-To: <1229038466.07.0.748042686463.issue4637@psf.upfronthosting.co.za> Message-ID: <1229038792.65.0.146513906818.issue4637@psf.upfronthosting.co.za> Guido van Rossum added the comment: This was discussed recently on python-dev (or was it python-ideas). The world is not ready for this. Please refer to the archive for motivation. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 01:14:10 2008 From: report at bugs.python.org (Akira Kitada) Date: Fri, 12 Dec 2008 00:14:10 +0000 Subject: [issue4010] configure options don't trickle down to distutils In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za> Message-ID: <1229040849.99.0.020319772412.issue4010@psf.upfronthosting.co.za> Akira Kitada added the comment: Is there anyone knowing the historical reason for this? In that case I will take this and submit a patch here soon. ---------- versions: +Python 2.5.3, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:15:51 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2008 01:15:51 +0000 Subject: [issue2736] datetime needs and "epoch" method In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za> Message-ID: <1229044551.46.0.495997967825.issue2736@psf.upfronthosting.co.za> STINNER Victor added the comment: belopolsky will be happy to see this new version of my patch: - datetime.totimestamp() => (seconds, microseconds): two integers - datetime.totimestamp() implement don't use Python time.mktime() but directly the C version of mktime() because time.mktime() creates a float value - fix time.mktime() to support the timestamp -1 (first second before the epoch) to make it consistent with datetime.totimestamp() which also support this value - fix documentation: it's microseconds (10^-6) and not milliseconds (10^-3) Added file: http://bugs.python.org/file12329/datetime_totimestamp-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:18:39 2008 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2008 01:18:39 +0000 Subject: [issue4010] configure options don't trickle down to distutils In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za> Message-ID: <1229044719.17.0.292748325651.issue4010@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:19:58 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2008 01:19:58 +0000 Subject: [issue2736] datetime needs and "epoch" method In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za> Message-ID: <1229044798.74.0.10784297027.issue2736@psf.upfronthosting.co.za> STINNER Victor added the comment: About mktime() -> -1: see the Issue1726687 (I found the fix in this issue). Next job will be to patch datetime.(utc)fromtimestamp() to support (int, int). I tried to write such patch but it's not easy because fromtimestamp() will support: int, long, float, (int, int), (int, long), (long, int) and (long, long). And I don't know if a "long" value can be converted to "time_t". _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:25:49 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 12 Dec 2008 01:25:49 +0000 Subject: [issue4021] tokenize.detect_encoding(): raise SyntaxError on codecs.lookup() error In-Reply-To: <1222988433.37.0.412294241613.issue4021@psf.upfronthosting.co.za> Message-ID: <1229045149.39.0.771483956103.issue4021@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r67711. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:33:53 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 12 Dec 2008 01:33:53 +0000 Subject: [issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open() In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za> Message-ID: <1229045633.23.0.842497294386.issue4016@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Applied in r67713. ---------- nosy: +benjamin.peterson resolution: -> accepted status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:46:02 2008 From: report at bugs.python.org (Hatem) Date: Fri, 12 Dec 2008 01:46:02 +0000 Subject: [issue4638] 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true In-Reply-To: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za> Message-ID: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za> New submission from Hatem : In [29]: a,b = 1.0,1.0 In [30]: a is b Out[30]: True In [31]: a = 1.0 In [32]: b = 1.0 In [33]: a is b Out[33]: False # ?!? ---------- components: Interpreter Core messages: 77654 nosy: nassrat severity: normal status: open title: 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:50:43 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Dec 2008 01:50:43 +0000 Subject: [issue4638] 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true In-Reply-To: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za> Message-ID: <1229046643.26.0.462754661678.issue4638@psf.upfronthosting.co.za> Gregory P. Smith added the comment: this is not a bug. ask this type of question on comp.lang.python. in short: 'is' is not an equality comparison operator. it compares object instance identity. ---------- nosy: +gregory.p.smith resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:54:16 2008 From: report at bugs.python.org (Hatem) Date: Fri, 12 Dec 2008 01:54:16 +0000 Subject: [issue4638] 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true In-Reply-To: <1229046643.26.0.462754661678.issue4638@psf.upfronthosting.co.za> Message-ID: <2238dbfb0812111754h7740cf66i269220788945b77a@mail.gmail.com> Hatem added the comment: Really, "is" is not equality but is object equivalence, wow I did not know that. So why is the first one true MR. This is truly a bug, why is the first one optimized while the second one isn't. And how come integers are allways optimized in that sense. Go close other tickets. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:54:57 2008 From: report at bugs.python.org (Tim Peters) Date: Fri, 12 Dec 2008 01:54:57 +0000 Subject: [issue4638] 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true In-Reply-To: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za> Message-ID: <1229046897.45.0.28118543302.issue4638@psf.upfronthosting.co.za> Tim Peters added the comment: "is" is for testing object identity, not numeric equality. That "1 is 1" is always true is simply an implementation detail common to all recent versions of CPython, due to CPython caching "very small" integer objects. The language definition neither requires nor forbids this, so any program relying on it is in error. Likewise any program relying on "1.0 is 1.0" being false is also in error. ---------- nosy: +tim_one _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:58:25 2008 From: report at bugs.python.org (Hatem) Date: Fri, 12 Dec 2008 01:58:25 +0000 Subject: [issue4638] 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true In-Reply-To: <1229046897.45.0.28118543302.issue4638@psf.upfronthosting.co.za> Message-ID: <2238dbfb0812111758x35503090s71d06610131ec5c7@mail.gmail.com> Hatem added the comment: Atleast you didnt really challenge my inelegence like greg did. If you look at my small interpreted session, is returned true the first time. Why is that. The ticket title may not have been perfect, I was trying to be sarcastic/funny. I am asking why are objects sometime the same instance while sometimes aren't for floats. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 03:01:55 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 12 Dec 2008 02:01:55 +0000 Subject: [issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open() In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za> Message-ID: <1229047315.99.0.751213271911.issue4016@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I had to revert this because tokenize imports itertools. This is a problem when building (setup.py) because itertools doesn't exist, yet. I also think we should consider hard adding more modules that are loaded at startup time to py3k already huge list. ---------- resolution: accepted -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 03:02:06 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Dec 2008 02:02:06 +0000 Subject: [issue4638] 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true In-Reply-To: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za> Message-ID: <1229047326.33.0.585130722622.issue4638@psf.upfronthosting.co.za> Gregory P. Smith added the comment: the only intelligence i'm challenging is that this is not appropriate for a bug tracker. bring it up on a users mailing list. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 03:03:53 2008 From: report at bugs.python.org (Forest Wilkinson) Date: Fri, 12 Dec 2008 02:03:53 +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: <1229047433.84.0.651406561476.issue1856@psf.upfronthosting.co.za> Changes by Forest Wilkinson : ---------- nosy: +forest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 03:15:54 2008 From: report at bugs.python.org (Forest Wilkinson) Date: Fri, 12 Dec 2008 02:15:54 +0000 Subject: [issue1720705] thread + import => crashes? Message-ID: <1229048154.83.0.342037326674.issue1720705@psf.upfronthosting.co.za> Changes by Forest Wilkinson : ---------- nosy: +forest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 03:39:31 2008 From: report at bugs.python.org (Tim Peters) Date: Fri, 12 Dec 2008 02:39:31 +0000 Subject: [issue4638] 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true In-Reply-To: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za> Message-ID: <1229049571.81.0.137244554998.issue4638@psf.upfronthosting.co.za> Tim Peters added the comment: Please take requests for discussion to comp.lang.python. Many people there understand this behavior and will be happy to explain it in as much detail as you want. The bug tracker is not the place for this. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 10:36:01 2008 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 12 Dec 2008 09:36:01 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1229074561.22.0.106922032614.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: I still don't see the problem: Py_buffer is a minimal description of a region of memory. No more, no less. It doesn't *do* anything, it's just a description. memoryview is an object that will (when it's finished) provide an easy way to access the memory of another object. Having a fairly raw low level API (Py_buffer/PyObject_GetBuffer/PyBuffer_Release) and a higher level, more convenient, but higher overhead API (memoryview) seems like a perfectly natural split to me. Multi-level APIs are a great way of freeing the more abstract interface from the need to handle every single possible edge case - we can quite reasonably tell people that care about the more obscure edge cases to drop down a level and handle them with the raw API. We just need to finish the job of making the convenience wrapper actually able to handle the task we would like it to handle. Your latest patch goes a long way towards doing that for the 1 dimensional case - if Travis doesn't get to it first, I plan on taking a look a closer look at it this weekend. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 10:47:04 2008 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 12 Dec 2008 09:47:04 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1229075224.4.0.419550084268.issue4580@psf.upfronthosting.co.za> Nick Coghlan added the comment: Trying another way of getting the point across... if Py_buffer wasn't defined in PEP 3118, there would have to be some *other* API there whereby the memoryview implementation could ask an object for a description of the data layout of the object's buffer. It is Py_buffer which allows the implementation of memoryview to even be contemplated. The one point where the PEP is silent (and I think this might be what you've been attempting to get at) is as to whether or not it is OK for a client to *modify* the contents of the Py_buffer structure before passing it back in to PyBuffer_Release. And to that I would say that a robust type implementation shouldn't be assuming *anything* about the contents of the Py_buffer passed to PyBuffer_Release. If it needs to do more than decrement a reference count when the buffer is released (e.g. releasing memory allocated for shapes and strides information), then it should be doing its own internal bookkeeping based on the address of the Py_buffer object originally passed to PyObject_GetBuffer. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:44:56 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 12 Dec 2008 11:44:56 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1228898699.93.0.265274006769.issue3248@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Wed, Dec 10, 2008 at 6:44 AM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > What problem is solved by ScrolledText.diff that isn't already solved by > scrolledtext_masterstr.diff? None. The later is a cleanup of ScrolledText.py. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:09:49 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 12 Dec 2008 12:09:49 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: <1228896915.2.0.573622519652.issue4342@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Wed, Dec 10, 2008 at 6:15 AM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > I'm skeptical about backporting r59654. Doing so might break existing > applications. > I don't see in what way it would break existing applications. The indices returned by that command in Tcl should all be represented as strings in Python, so I see this at max causing a double attempt to convert it to str. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:35:42 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 12 Dec 2008 12:35:42 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: <1228897302.15.0.0167451283154.issue4342@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Wed, Dec 10, 2008 at 6:21 AM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > Can you remind me what problem was fixed with r59653? I can't find the > Tk tracker anymore on which this apparently was reported. > I had trouble finding it too, it was redirected to somewhere else and marked as private because of spam. I asked a tk developer for the issue and he kindly pasted the comments here: http://paste.tclers.tk/1381?v=raw I didn't want to go offtopic here but it raises a question about handling bgerror and I don't know where else I should ask this so.. I have been working on a new _tkinter (before I went traveling, back now) and I have been supporting the use of bgerror but would like to know what kind of problems it used to cause to Tkinter or _tkinter. For IDLE specifically I had to disable it. > If it fixes a problem with supporting Tcl 8.5, then I will also reject > the request. Supporting Tcl 8.5 is a new feature, and should thus not be > added to 2.5.3. Only Tcl up to 8.4 is support by Python 2.5. > But if it doesn't affect anything in the current usage, why not backport such patch ? Even though you can say that tcl 8.5 is not supported by python 2.5, _tkinter doesn't enforce this. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:11:19 2008 From: report at bugs.python.org (Edd) Date: Fri, 12 Dec 2008 14:11:19 +0000 Subject: [issue4639] Build failure on OpenBSD 4.4-current regarding lstat() In-Reply-To: <1229091079.2.0.148699699558.issue4639@psf.upfronthosting.co.za> Message-ID: <1229091079.2.0.148699699558.issue4639@psf.upfronthosting.co.za> New submission from Edd : Hi, I just had to move the "extern lstat..." outside the "ifndef HAVE_LSTAT" to get python 2.6.1 to build on OpenBSD 4.4-current/i386. I'm not suggesting this is correct, but it fixes the build for my platform at least. --- Modules/posixmodule.c.orig Fri Dec 12 11:08:54 2008 +++ Modules/posixmodule.c Fri Dec 12 11:54:16 2008 @@ -208,10 +208,11 @@ #ifdef HAVE_SYMLINK extern int symlink(const char *, const char *); #endif /* HAVE_SYMLINK */ +#endif /* !HAVE_UNISTD_H */ + #ifdef HAVE_LSTAT extern int lstat(const char *, struct stat *); #endif /* HAVE_LSTAT */ -#endif /* !HAVE_UNISTD_H */ #endif /* !_MSC_VER */ Im using gcc-4.2 Thanks ---------- components: Build messages: 77667 nosy: vext01 severity: normal status: open title: Build failure on OpenBSD 4.4-current regarding lstat() type: compile error versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:14:43 2008 From: report at bugs.python.org (Krzysztof Szawala) Date: Fri, 12 Dec 2008 14:14:43 +0000 Subject: [issue4640] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za> Message-ID: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za> New submission from Krzysztof Szawala : I am using optparse for command-line parameters parsing. To follow common naming convention I defined -d (minus followed by a single character option) and --debug (double minus followed by a word). It looks like optparse doesn't complain when -debug (single minus) is specified and morover it doesn't recognize it as --debug. I am using Python 2.5.2. Problem was observed on Linux but also occurs on Windows. ---------- components: Extension Modules messages: 77668 nosy: kszawala severity: normal status: open title: optparse - dosn't distinguish between '--option' and '-option' type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:15:18 2008 From: report at bugs.python.org (Krzysztof Szawala) Date: Fri, 12 Dec 2008 14:15:18 +0000 Subject: [issue4641] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091317.99.0.0373264800508.issue4641@psf.upfronthosting.co.za> Message-ID: <1229091317.99.0.0373264800508.issue4641@psf.upfronthosting.co.za> New submission from Krzysztof Szawala : I am using optparse for command-line parameters parsing. To follow common naming convention I defined -d (minus followed by a single character option) and --debug (double minus followed by a word). It looks like optparse doesn't complain when -debug (single minus) is specified and morover it doesn't recognize it as --debug. I am using Python 2.5.2. Problem was observed on Linux but also occurs on Windows. ---------- components: Extension Modules messages: 77669 nosy: kszawala severity: normal status: open title: optparse - dosn't distinguish between '--option' and '-option' type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:16:44 2008 From: report at bugs.python.org (Krzysztof Szawala) Date: Fri, 12 Dec 2008 14:16:44 +0000 Subject: [issue4642] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091404.39.0.274504752383.issue4642@psf.upfronthosting.co.za> Message-ID: <1229091404.39.0.274504752383.issue4642@psf.upfronthosting.co.za> New submission from Krzysztof Szawala : I am using optparse for command-line parameters parsing. To follow common naming convention I defined -d (minus followed by a single character option) and --debug (double minus followed by a word). It looks like optparse doesn't complain when -debug (single minus) is specified and morover it doesn't recognize it as --debug. I am using Python 2.5.2. Problem was observed on Linux but also occurs on Windows. ---------- components: Extension Modules messages: 77670 nosy: kszawala severity: normal status: open title: optparse - dosn't distinguish between '--option' and '-option' type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:28:06 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 12 Dec 2008 14:28:06 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1229074561.22.0.106922032614.issue4580@psf.upfronthosting.co.za> Message-ID: <1229092041.12840.4.camel@localhost> Antoine Pitrou added the comment: > We just need to finish the job of making the convenience wrapper > actually able to handle the task we would like it to handle. Your latest > patch goes a long way towards doing that for the 1 dimensional case - if > Travis doesn't get to it first, I plan on taking a look a closer look at > it this weekend. Ok, thanks. I hope we can at least solve this bunch of severe problems before 3.0.1 :-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:48:33 2008 From: report at bugs.python.org (Allan Crooks) Date: Fri, 12 Dec 2008 14:48:33 +0000 Subject: [issue4643] cgitb.html fails if getattr call raises exception In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> Message-ID: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> New submission from Allan Crooks : If cgitb.html tries to get the value of an attribute from an object, and the getattr call causes an exception to be raised (other than an AttributeError), then cgitb.html fails to work: If you run the attached file in Python 2.5.2 or 2.6, you get the following output: ---- A: the letter a B: Something went wrong - attempting to generate HTML stack trace. Error generating HTML stack trace! Traceback (most recent call last): File "attrtest.py", line 21, in html_text = cgitb.html(sys.exc_info()) File "C:\python26\lib\cgitb.py", line 133, in html vars = scanvars(reader, frame, locals) File "C:\python26\lib\cgitb.py", line 84, in scanvars value = getattr(parent, token, __UNDEF__) File "attrtest.py", line 8, in __getattr__ return str(slf) # Intentional NameError NameError: global name 'slf' is not defined ---- The problem is in the scanvars function - it offers no protection against any unexpected exceptions that occur (that escape the getattr call) - which can be a problem if it is the same problematic code that caused cgitb.html to be called in the first place. I think scanvars should catch any exceptions that come from the getattr call and either mention that the attribute value could not be determined, or simply omit the mention of the attribute at all. If the line in the attached file is commented out, then the next line is caught appropriately and formatted correctly (the offending code occurs in the same block, but doesn't cause the same problem because it raises an AttributeError). ---------- components: Library (Lib) files: attrtest.py messages: 77672 nosy: amc1 severity: normal status: open title: cgitb.html fails if getattr call raises exception versions: Python 2.5.3, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file12330/attrtest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:53:59 2008 From: report at bugs.python.org (Allan Crooks) Date: Fri, 12 Dec 2008 14:53:59 +0000 Subject: [issue4644] Minor documentation fault in 2to3 script In-Reply-To: <1229093639.22.0.0185792170077.issue4644@psf.upfronthosting.co.za> Message-ID: <1229093639.22.0.0185792170077.issue4644@psf.upfronthosting.co.za> New submission from Allan Crooks : When I run the following command: C:\temp>\python26\Tools\scripts\2to3.py --help Usage: refactor.py [options] file|dir ... It mentions that the script name is refactor.py, rather than 2to3.py (I guess that was the scripts original name?) ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 77673 nosy: amc1 severity: normal status: open title: Minor documentation fault in 2to3 script type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:54:11 2008 From: report at bugs.python.org (Allan Crooks) Date: Fri, 12 Dec 2008 14:54:11 +0000 Subject: [issue4643] cgitb.html fails if getattr call raises exception In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> Message-ID: <1229093651.79.0.296300634385.issue4643@psf.upfronthosting.co.za> Changes by Allan Crooks : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 16:23:08 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 12 Dec 2008 15:23:08 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1229095388.89.0.991396794861.issue4616@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I checked the necessary changes in the trunk and the py3k, release26-maint, and release30-maint branches (r67717-r67720). Thank you for your report. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 17:50:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 16:50:15 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229100615.32.0.735797361223.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Victor, This looks good. If it's okay with you, I'll work on the documentation a little (we need an entry in whatsnew, and a description of the semantics of numbits for 0 and negative integers.) Then I think this will be ready. > I prefer to keep the "fast path" (use _PyLong_NumBits) as *you* > proposed in another message: Message75767. Sorry---I wasn't clear. I wasn't suggesting getting rid of the fast path---I was suggesting inlining the _PyLong_NumBits code in long_numbits (leaving _PyLong_NumBits itself intact, of course). It would eliminate all the messing around with exceptions. But I think the current code is fine. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 17:56:34 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2008 16:56:34 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229100994.21.0.103514408264.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'll work on the documentation Ok, cool. > a description of the semantics of numbits for 0 and negative integers About the negative integer: the documentation should be "number of bits of the *absolute value* of x" and "by convention, 0.numbits() is 0". But you're right, the documentation is not clear. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:26:06 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 17:26:06 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229102766.46.0.764896873316.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's Victor's patch, but with extra documentation. No code has been changed. Two more questions about the code, Victor; specifically about long_numbits: - why do you use PyLong_FromSize_t rather than PyInt_FromSize_t? - isn't the if (ndigits == 0) check redundant? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:26:36 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 17:26:36 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229102796.98.0.95951344413.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Oops. Here's the patch. Added file: http://bugs.python.org/file12331/numbits-6a.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:29:14 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 17:29:14 +0000 Subject: [issue4642] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091404.39.0.274504752383.issue4642@psf.upfronthosting.co.za> Message-ID: <1229102954.54.0.114536006053.issue4642@psf.upfronthosting.co.za> Mark Dickinson added the comment: Duplicate of issue #4640. ---------- nosy: +marketdickinson resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:29:41 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 17:29:41 +0000 Subject: [issue4641] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091317.99.0.0373264800508.issue4641@psf.upfronthosting.co.za> Message-ID: <1229102981.04.0.0748842485824.issue4641@psf.upfronthosting.co.za> Mark Dickinson added the comment: Duplicate of issue #4640. ---------- nosy: +marketdickinson resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 19:03:15 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2008 18:03:15 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1229102766.46.0.764896873316.issue3439@psf.upfronthosting.co.za> Message-ID: <200812121902.43354.victor.stinner@haypocalc.com> STINNER Victor added the comment: > - why do you use PyLong_FromSize_t rather than PyInt_FromSize_t? I choosed to use consistent result type. But now I would prefer int :-) I see that PyInt_FromSize_t() returns a long if the value doesn't fit in an int. So it's correct. > - isn't the if (ndigits == 0) check redundant? I'm paranoid: if _PyLong_NumBits() fails but the number is zero, the function may crash. But this case is impossible: _PyLong_NumBits() can only fails with an OverflowError. Can you fix these two issues (use PyInt_FromSize_t and remove the if)? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 19:10:46 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 18:10:46 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229105446.49.0.825337214884.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I choosed to use consistent result type. But now I would prefer int :-) I see > that PyInt_FromSize_t() returns a long if the value doesn't fit in an int. So > it's correct. Cool. I think int is better, simply because the result is almost always going to fit into an int in practice, and because calculations with ints are faster. > I'm paranoid Yeah, me too. I removed the check, but also changed the assert to check that Py_SIZE is nonzero. > Can you fix these two issues (use PyInt_FromSize_t and remove the if)? Done. Added file: http://bugs.python.org/file12332/numbits-6b.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 19:10:51 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 18:10:51 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229105451.2.0.761415604938.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12331/numbits-6a.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 19:33:00 2008 From: report at bugs.python.org (David W. Lambert) Date: Fri, 12 Dec 2008 18:33:00 +0000 Subject: [issue4640] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za> Message-ID: <1229106780.71.0.507547932405.issue4640@psf.upfronthosting.co.za> David W. Lambert added the comment: When I use it on python 3 optparse reports no such option -e, which is correct since the form -debug permits a run of single character options. ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 19:44:21 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2008 18:44:21 +0000 Subject: [issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open() In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za> Message-ID: <1229107461.72.0.591582876492.issue4016@psf.upfronthosting.co.za> STINNER Victor added the comment: It was easy to remove the itertools dependency: only itertools.chain() was really used and a simple "for ...: yield" is enough to get the same behaviour (test_tokenize.py runs fine). With the new version of the patch, the bootstrap works correctly. Added file: http://bugs.python.org/file12333/linecache_refactor-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 19:44:25 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2008 18:44:25 +0000 Subject: [issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open() In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za> Message-ID: <1229107465.94.0.00236369468027.issue4016@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file11678/linecache_refactor.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 20:51:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Dec 2008 19:51:19 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229111479.19.0.289975195247.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: As far as I'm concerned, this patch is ready to be applied. Raymond, care to give a second opinion? ---------- assignee: marketdickinson -> rhettinger stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 21:10:16 2008 From: report at bugs.python.org (Shawn Ashlee) Date: Fri, 12 Dec 2008 20:10:16 +0000 Subject: [issue4645] configparser DEFAULT In-Reply-To: <1229112616.18.0.592196405919.issue4645@psf.upfronthosting.co.za> Message-ID: <1229112616.18.0.592196405919.issue4645@psf.upfronthosting.co.za> New submission from Shawn Ashlee : using .add_section() and .set() for the DEFAULT section adds it twice: [user at srv ~]$ cat test_configparser.py #!/usr/bin/env python import ConfigParser a = ConfigParser.SafeConfigParser() # borked a.add_section('DEFAULT') a.set('DEFAULT', 'foo', 'bar') # working a.add_section('working') a.set('working', 'foo', 'bar') b = open('testing', 'w') a.write(b) b.close() [user at srv ~]$ python test_configparser.py [user at srv ~]$ cat testing [DEFAULT] foo = bar [DEFAULT] [working] foo = bar Tested with 2.4 and 2.5, py3k no longer allows DEFAULT to be passed, so this is a python < 3k issue. ---------- components: Extension Modules messages: 77686 nosy: shawn.ashlee severity: normal status: open title: configparser DEFAULT versions: Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 21:15:04 2008 From: report at bugs.python.org (Thomas Heller) Date: Fri, 12 Dec 2008 20:15:04 +0000 Subject: [issue4646] distutils chokes on empty options arg in the setup function In-Reply-To: <1229112904.14.0.0159399234206.issue4646@psf.upfronthosting.co.za> Message-ID: <1229112904.14.0.0159399234206.issue4646@psf.upfronthosting.co.za> New submission from Thomas Heller : Distutils setup function accepts an 'options' named argument which allows to pass options to subcommands in a dictionary (At the moment I cannot find where this is documented). When an empty dictionary is passed, distutils spits out a warning: C:\sf\comtypes>py3 setup.py clean c:\python30\lib\distutils\dist.py:259: UserWarning: Unknown distribution option: 'options' warnings.warn(msg) running clean ... I believe the bug is in all versions of Python; since it never has been fixed (or even found) I'm not sure if it is worth fixing. However, patch is attached. ---------- components: Distutils files: distutils.patch keywords: patch, patch messages: 77687 nosy: theller severity: normal status: open title: distutils chokes on empty options arg in the setup function type: behavior versions: Python 2.5.3, Python 2.6, Python 2.7, Python 3.0 Added file: http://bugs.python.org/file12334/distutils.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 22:27:11 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 12 Dec 2008 21:27:11 +0000 Subject: [issue4477] Speed up PyEval_EvalFrameEx when tracing is off. In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za> Message-ID: <1229117231.03.0.512084938399.issue4477@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Merged to 3.1 in r67611, 3.0.x in r67721, and 2.6.x in r67722. ---------- keywords: -needs review status: open -> closed versions: +Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 23:47:54 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Dec 2008 22:47:54 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229122074.03.0.102121953941.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The code looks fine. For speed, you could insert the following just before the while-loop: while (n >= 256) { n >>= 8; result += 8; } Am not sure the "numbits" is the right-name. Is there precedent in other languages or texts on bit-twiddling techniques? For numbits(0b0100), I could forsee people predicting a result of 4, 3, or 1 depending on their world-view of what numbits might mean. Personally, I tend to think in term of high-bit location or somesuch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 23:50:21 2008 From: report at bugs.python.org (Kay Schluehr) Date: Fri, 12 Dec 2008 22:50:21 +0000 Subject: [issue4647] Builtin parser module fails to parse relative imports In-Reply-To: <1229122221.79.0.426361145123.issue4647@psf.upfronthosting.co.za> Message-ID: <1229122221.79.0.426361145123.issue4647@psf.upfronthosting.co.za> New submission from Kay Schluehr : I've added the following test method: test_parser.py -------------- class RoundtripLegalSyntaxTestCase(unittest.TestCase): def test_relative_import_statement(self): self.check_suite("from . import sys") The test fails raising the message: Traceback (most recent call last): File "test_parser.py", line 182, in test_relative_import_statement self.check_suite("from . import sys") File "test_parser.py", line 29, in check_suite self.roundtrip(parser.suite, s) File "test_parser.py", line 20, in roundtrip self.fail("could not roundtrip %r: %s" % (s, why)) AssertionError: could not roundtrip 'from . import sys': Expected node type 1, got 23. Apparently the parser expects a NAME token and gets a DOT token. This behaviour affects Python 2.5 and Python 2.6. Unchecked for Python 3.0. ---------- components: Interpreter Core messages: 77690 nosy: schluehk severity: normal status: open title: Builtin parser module fails to parse relative imports type: behavior versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:03:45 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Dec 2008 23:03:45 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1229123025.48.0.44706758394.issue4617@psf.upfronthosting.co.za> Terry J. Reedy added the comment: -1 as I understand the proposal. Your code is bugged and should fail as soon as possible. If I understand correctly, you agree that the SyntaxError is correct as the language is currently defined, but you want the definition changed. It is not clear if you only want implicit deletes at the end of except clauses to work or if you only want explicit deletes to work. If the latter, you want def f(): e = 1 del e def g(): print(e) return g to compile. I would not. Your reason "After all, the "variable referenced" has no value before it is set," (duh, right) makes no sense to me in this context. g must have a valid value of e to run. So you seem to be suggesting that detection of buggy code should be delayed. ---------- nosy: +tjreedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:06:21 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Dec 2008 23:06:21 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: Message-ID: <4942EE6A.9010002@v.loewis.de> Martin v. L?wis added the comment: > I don't see in what way it would break existing applications. The > indices returned by that command in Tcl should all be represented as > strings in Python, so I see this at max causing a double attempt to > convert it to str. I can't quite follow your terminology: what indices? I can imagine many cases where conversion using Python's str() gives a different result than the conversion through Tcl objects. For example, if Python returns a bool, 2.5 will pass 'True' to Tcl. 2.6 will convert this to a Tcl boolean, whose string representation is '1'. If you are saying that the Python command *should* return strings always, then this assumption is precisely a candidate for breakage: people might currently be returning all kinds of things to Tcl in callbacks (even outside Tkinter), and we might break these applications. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:29:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Dec 2008 23:29:13 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1229124553.23.0.6988651496.issue4617@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Not sure the "del e" idea was a good solution to the garbage collection problem. Amaury's code looks correct to me. Maybe the existing e variable should be overwritten and the left intact (as it used to be) or perhaps it should be made both temporary and invisible like the induction variable in a list comprehension. Phillip, any thoughts? ---------- assignee: -> pje nosy: +pje, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:34:07 2008 From: report at bugs.python.org (Retro) Date: Fri, 12 Dec 2008 23:34:07 +0000 Subject: [issue4648] Fix n//x to n/x in the Docs In-Reply-To: <1229124847.63.0.939793321835.issue4648@psf.upfronthosting.co.za> Message-ID: <1229124847.63.0.939793321835.issue4648@psf.upfronthosting.co.za> New submission from Retro : Please look at the example code in the following Python 3.0 documentation/tutorial: http://docs.python.org/3.0/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops The line 4 has a little fix to be made: from ... print(n, 'equals', x, '*', n//x) to ... print(n, 'equals', x, '*', n/x) You probably noticed that n//x was proposed to be fixed to n/x. Please note that this is Python 3.0 code. It's a small fix so I hope you won't mind to fix this. ---------- assignee: georg.brandl components: Documentation messages: 77694 nosy: Retro, georg.brandl severity: normal status: open title: Fix n//x to n/x in the Docs versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:39:00 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Dec 2008 23:39:00 +0000 Subject: [issue4648] Fix n//x to n/x in the Docs In-Reply-To: <1229124847.63.0.939793321835.issue4648@psf.upfronthosting.co.za> Message-ID: <1229125140.35.0.290084630959.issue4648@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The code is correct as it stands. If you still think this is a problem, please explain why you think the example should be changed. ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:49:05 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 12 Dec 2008 23:49:05 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1229125745.82.0.297640339854.issue4617@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Terry, my motivation is that the sample code above runs correctly with python 2.6, but python 3.0 cannot even compile it. The sample looks valid python code, and should run. Yes, the same 'e' is used both as a nested variable and as an exception target, but this should not matter with our dynamic language. First I thought to turn the implicit "del e" into something else (and change PEP3110), but then I saw that the error "can not delete variable referenced in nested scope" is actually a limitation of the interpreter that is easy to remove. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:56:20 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 12 Dec 2008 23:56:20 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: <4942EE6A.9010002@v.loewis.de> Message-ID: Guilherme Polo added the comment: On Fri, Dec 12, 2008 at 9:06 PM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > >> I don't see in what way it would break existing applications. The >> indices returned by that command in Tcl should all be represented as >> strings in Python, so I see this at max causing a double attempt to >> convert it to str. > > I can't quite follow your terminology: what indices? > > I can imagine many cases where conversion using Python's str() gives > a different result than the conversion through Tcl objects. For example, > if Python returns a bool, 2.5 will pass 'True' to Tcl. 2.6 will convert > this to a Tcl boolean, whose string representation is '1'. > > If you are saying that the Python command *should* return strings > always, then this assumption is precisely a candidate for breakage: > people might currently be returning all kinds of things to Tcl in > callbacks (even outside Tkinter), and we might break these > applications. > Are we talking about the same commit ? 59654 as in your original about it breaking existing code. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:59:04 2008 From: report at bugs.python.org (Retro) Date: Fri, 12 Dec 2008 23:59:04 +0000 Subject: [issue4648] Fix n//x to n/x in the Docs In-Reply-To: <1229124847.63.0.939793321835.issue4648@psf.upfronthosting.co.za> Message-ID: <1229126344.46.0.112982525583.issue4648@psf.upfronthosting.co.za> Retro added the comment: For Python 2.x that example code is fine, but Python 3.0 has this switched now. Please read http://www.python.org/dev/peps/pep-0238/. True division in Python 3.0 is done with one division operator. Please fix that code example to reflect that. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:13:54 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 00:13:54 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: Message-ID: <4942FE3F.4010601@v.loewis.de> Martin v. L?wis added the comment: > Are we talking about the same commit ? 59654 as in your original about > it breaking existing code. Oops, no. I now see that r59654 is fine for backporting. My last message was about r59653, which probably does introduce backward compatibility problems. The other changes seem to introduce new features, so they are out of scope. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:19:00 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 00:19:00 +0000 Subject: [issue4648] Fix n//x to n/x in the Docs In-Reply-To: <1229126344.46.0.112982525583.issue4648@psf.upfronthosting.co.za> Message-ID: <4942FF71.8000903@v.loewis.de> Martin v. L?wis added the comment: > For Python 2.x that example code is fine, but Python 3.0 has this > switched now. Please read http://www.python.org/dev/peps/pep-0238/. > > True division in Python 3.0 is done with one division operator. Please > fix that code example to reflect that. I still don't understand. The example doesn't, and shouldn't, use true division. It does, and should, use floor division, to display the divisors of a non-prime. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:21:10 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 00:21:10 +0000 Subject: [issue4648] Fix n//x to n/x in the Docs In-Reply-To: <1229124847.63.0.939793321835.issue4648@psf.upfronthosting.co.za> Message-ID: <1229127670.11.0.402841557619.issue4648@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Retro, the code is correct as it stands. Floor division is intended (int // int --> int). I think you've misunderstood true division where the / operator used to mean floor division when supplied with integer arguments but now returns a float instead. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:21:21 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Sat, 13 Dec 2008 00:21:21 +0000 Subject: [issue4645] configparser DEFAULT In-Reply-To: <1229112616.18.0.592196405919.issue4645@psf.upfronthosting.co.za> Message-ID: <1229127681.42.0.300656157133.issue4645@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: This is already fixed in 2.6 since r60976, the related issue is #1781 I'm not sure this is a good candidate for 2.4.6 and 2.5.3 : this isn't a security fix, but I doubt fixing this would break existing code as I can't imagine people relying on this behavior. Adding Martin to the nosy list so he can pronounce. ---------- nosy: +loewis, quentin.gallet-gilles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:37:23 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Sat, 13 Dec 2008 00:37:23 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1229128643.03.0.354797019319.issue4617@psf.upfronthosting.co.za> Phillip J. Eby added the comment: I could argue either way on this one; it's true that deleting a nested-scope variable is sometimes desirable, but it also seems to me like closing over an except: variable is a Potentially Bad Idea. In neither case, however, do I think it's appropriate to drop the temporary nature of the variable. I could perhaps get behind resetting the variable to None instead of deleting it, but of course the PEP would need changing. There's also a question of whether we should do the same thing with "with ... as" variables. (Btw, I'm not sure why this one's assigned to me; ISTM I might have proposed the current except/as GC semantics, but I'm not familiar with the actual implementation in 2.6 or 3.0) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:48:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 00:48:42 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1229129322.8.0.686027409225.issue4617@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, any thoughts? ---------- assignee: pje -> gvanrossum nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:53:28 2008 From: report at bugs.python.org (Retro) Date: Sat, 13 Dec 2008 00:53:28 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> New submission from Retro : http://docs.python.org/3.0/tutorial/controlflow.html#defining-functions Please visit the above link and see line 6 in the example code. ... a, b = b, a+b should be fixed to ... a, b = b, a + b because PEP 8 recommends to - Use spaces around arithmetic operators: Yes: i = i + 1 No: i=i+1 ---------- assignee: georg.brandl components: Documentation messages: 77705 nosy: Retro, georg.brandl, loewis, rhettinger severity: normal status: open title: Fix a+b to a + b versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:00:24 2008 From: report at bugs.python.org (Retro) Date: Sat, 13 Dec 2008 01:00:24 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229130024.84.0.851531545328.issue4649@psf.upfronthosting.co.za> Retro added the comment: And please fix the code example mentioned in issue4648. Line 4 has a little fix to be made: from ... print(n, 'equals', x, '*', n//x) to ... print(n, 'equals', x, '*', n // x) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:42:39 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 13 Dec 2008 01:42:39 +0000 Subject: [issue4647] Builtin parser module fails to parse relative imports In-Reply-To: <1229122221.79.0.426361145123.issue4647@psf.upfronthosting.co.za> Message-ID: <1229132559.32.0.520671994511.issue4647@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This has been fixed in 2.6.1 and will be in 2.5.3. ---------- nosy: +benjamin.peterson resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:44:36 2008 From: report at bugs.python.org (David W. Lambert) Date: Sat, 13 Dec 2008 01:44:36 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229132676.09.0.157772428795.issue4649@psf.upfronthosting.co.za> David W. Lambert added the comment: I do think your interpretation of PEP8 is overly strict. Here's the source code of the first j interpreter. (Ken Iverson) typedef char C;typedef long I; typedef struct a{I t,r,d[3],p[2];}*A; #define P printf #define R return #define V1(f) A f(w)A w; #define V2(f) A f(a,w)A a,w; #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}} I *ma(n){R(I*)malloc(n*4);}mv(d,s,n)I *d,*s;{DO(n,d[i]=s[i]);} tr(r,d)I *d;{I z=1;DO(r,z=z*d[i]);R z;} A ga(t,r,d)I *d;{A z=(A)ma(5+tr(r,d));z->t=t,z->r=r,mv(z->d,d,r); R z;} V1(iota){I n=*w->p;A z=ga(0,1,&n);DO(n,z->p[i]=i);R z;} V2(plus){I r=w->r,*d=w->d,n=tr(r,d);A z=ga(0,r,d); DO(n,z->p[i]=a->p[i]+w->p[i]);R z;} V2(from){I r=w->r-1,*d=w->d+1,n=tr(r,d); A z=ga(w->t,r,d);mv(z->p,w->p+(n**a->p),n);R z;} V1(box){A z=ga(1,0,0);*z->p=(I)w;R z;} V2(cat){I an=tr(a->r,a->d),wn=tr(w->r,w->d),n=an+wn; A z=ga(w->t,1,&n);mv(z->p,a->p,an);mv(z->p+an,w->p,wn);R z;} V2(find){} V2(rsh){I r=a->r?*a->d:1,n=tr(r,a->p),wn=tr(w->r,w->d); A z=ga(w->t,r,a->p);mv(z->p,w->p,wn=n>wn?wn:n); if(n-=wn)mv(z->p+wn,z->p,n);R z;} V1(sha){A z=ga(0,1,&w->r);mv(z->p,w->d,w->r);R z;} V1(id){R w;}V1(size){A z=ga(0,0,0);*z->p=w->r?*w->d:1;R z;} pi(i){P("%d ",i);}nl(){P("\n");} pr(w)A w;{I r=w->r,*d=w->d,n=tr(r,d);DO(r,pi(d[i]));nl(); if(w->t)DO(n,P("< ");pr(w->p[i]))else DO(n,pi(w->p[i]));nl();} C vt[]="+{~<#,"; A(*vd[])()={0,plus,from,find,0,rsh,cat}, (*vm[])()={0,id,size,iota,box,sha,0}; I st[26]; qp(a){R a>='a'&&a<='z';}qv(a){R a<'a';} A ex(e)I *e;{I a=*e; if(qp(a)){if(e[1]=='=')R st[a-'a']=ex(e+2);a= st[ a-'a'];} R qv(a)?(*vm[a])(ex(e+1)):e[1]?(*vd[e[1]])(a,ex(e+2)):(A)a;} noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);*z->p=c-'0';R z;} verb(c){I i=0;for(;vt[i];)if(vt[i++]==c)R i;R 0;} I *wd(s)C *s;{I a,n=strlen(s),*e=ma(n+1);C c; DO(n,e[i]=(a=noun(c=s[i]))?a:(a=verb(c))?a:c);e[n]=0;R e;} main(){C s[99];while(gets(s))pr(ex(wd(s)));} ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:49:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 13 Dec 2008 01:49:52 +0000 Subject: [issue4644] Minor documentation fault in 2to3 script In-Reply-To: <1229093639.22.0.0185792170077.issue4644@psf.upfronthosting.co.za> Message-ID: <1229132992.46.0.836629445214.issue4644@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67723. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:11:09 2008 From: report at bugs.python.org (Retro) Date: Sat, 13 Dec 2008 02:11:09 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229134269.25.0.509653504089.issue4649@psf.upfronthosting.co.za> Retro added the comment: Let's set a good example in the documentation and follow PEP 8. For God's sake, this is the documentation of Python! Where else to set a good example than here? Let's see some PEP 8 in action, in the documentation! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:34:49 2008 From: report at bugs.python.org (David W. Lambert) Date: Sat, 13 Dec 2008 02:34:49 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229135689.92.0.0121476519603.issue4649@psf.upfronthosting.co.za> David W. Lambert added the comment: That phrase of PEP 8 means to me "Use spaces to visually group expressions according to precedence." _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:59:57 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 02:59:57 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229137197.3.0.827560361457.issue4649@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is silly. The current version better communicates its intended purpose. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 04:03:59 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 13 Dec 2008 03:03:59 +0000 Subject: [issue4605] 3.0 documentation mentions using maketrans from within the string module. In-Reply-To: <1228782629.1.0.4913210804.issue4605@psf.upfronthosting.co.za> Message-ID: <1229137439.69.0.28095040124.issue4605@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67724. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 05:24:58 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 04:24:58 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229142298.41.0.402187868684.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, here is a link to faster algorithms: http://www-graphics.stanford.edu/~seander/bithacks.html#IntegerLog _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 07:46:37 2008 From: report at bugs.python.org (Wang Chun) Date: Sat, 13 Dec 2008 06:46:37 +0000 Subject: [issue4650] getopt need re-factor... In-Reply-To: <1229150797.88.0.480483260709.issue4650@psf.upfronthosting.co.za> Message-ID: <1229150797.88.0.480483260709.issue4650@psf.upfronthosting.co.za> New submission from Wang Chun : I created #4629 a couple of days ago. And besides that issue, for Python 3.x, I guess we can remove getopt.error since Python 3.x does not have to backward compatible with Python 2.x. And another issue is, GetoptError does not render right error message with unicode_literals enabled in Python 2.6. ---------- components: Library (Lib) messages: 77715 nosy: wangchun severity: normal status: open title: getopt need re-factor... versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 07:47:29 2008 From: report at bugs.python.org (Wang Chun) Date: Sat, 13 Dec 2008 06:47:29 +0000 Subject: [issue4651] getopt need re-factor... In-Reply-To: <1229150849.35.0.710720272237.issue4651@psf.upfronthosting.co.za> Message-ID: <1229150849.35.0.710720272237.issue4651@psf.upfronthosting.co.za> New submission from Wang Chun : I created #4629 a couple of days ago. And besides that issue, for Python 3.x, I guess we can remove getopt.error since Python 3.x does not have to backward compatible with Python 2.x. And another issue is, GetoptError does not render right error message with unicode_literals enabled in Python 2.6. ---------- components: Library (Lib) messages: 77716 nosy: wangchun severity: normal status: open title: getopt need re-factor... versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 08:40:54 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sat, 13 Dec 2008 07:40:54 +0000 Subject: [issue4616] tarfile does not set the creation date and time of the extracted directories In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za> Message-ID: <1229154054.17.0.476044677043.issue4616@psf.upfronthosting.co.za> Changes by Lars Gust?bel : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 08:43:49 2008 From: report at bugs.python.org (Aki Wakabayashi) Date: Sat, 13 Dec 2008 07:43:49 +0000 Subject: [issue4652] IDLE does not work with Unicode In-Reply-To: <1229154229.3.0.726059762082.issue4652@psf.upfronthosting.co.za> Message-ID: <1229154229.3.0.726059762082.issue4652@psf.upfronthosting.co.za> New submission from Aki Wakabayashi : I have installed python 3.0 on Ubuntu 8.10 yesterday and played around with the new unicode features and had no problems with Japanese characters(both in interactive and script mode). However, after rebooting, IDLE will no longer let me input any Japanese characters. (I have it set to UFT-8, if it makes any difference anymore) The terminal works fine. It lets me input Japanese and runs commands correctly. So I used gedit and saved a simple print("Hello(in Japanese chars)"), and run it with IDLE 3.0 but I get a blank line >>>. (Can I also make sure that I'm opening IDLE correctly? This is how I do it: 1)Open Terminal 2)~$ Python.3.0 3)>>> input idlelib.idle Thank You in advance. ---------- components: IDLE messages: 77717 nosy: zzyzx severity: normal status: open title: IDLE does not work with Unicode type: performance versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 08:56:56 2008 From: report at bugs.python.org (Johnny Lee) Date: Sat, 13 Dec 2008 07:56:56 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> New submission from Johnny Lee : I ran my typo.pl perl script that locates possible C/C++ typos. I found four that looked valid. Two of the typos were in the Python directory {pythonrun.c, dynload_win.c}, two were in PC/bdist_wininst {install.c, extract.c}. Python/dynload_win.c: Win32 API FormatMessageW() expects the 6th parameter to be the count of characters, NOT the count of bytes. Python/pythonrun.c: The source code contains "if (ferr != NULL || ferr != Py_None)". This does not work as expected - if ferr == NULL, then the second part of the if expression will succeed. Look at the code handling fout about 8 lines up to see the correct code. PC/bdist_wininst/extract.c: Win32 API CreateFileMapping returns NULL on error, not INVALID_HANDLE_VALUE. PC/bdist_wininst/install.c: Win32 API CreateFileMapping returns NULL on error, not INVALID_HANDLE_VALUE. ---------- components: Installation, Interpreter Core files: py30diff.txt messages: 77718 nosy: typo.pl severity: normal status: open title: Patch to fix typos for Py3K versions: Python 3.0 Added file: http://bugs.python.org/file12335/py30diff.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 09:47:40 2008 From: report at bugs.python.org (dirlt) Date: Sat, 13 Dec 2008 08:47:40 +0000 Subject: [issue4654] os.path.realpath() get the wrong result In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za> Message-ID: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za> New submission from dirlt : I found the problem when i install a small tool which I wrote on the each machine in the company.the problem is simplified as follows: there are three files 1./home/share/temp/a a regular file 2./home/share/a.lnk which is symbolic link to the /home/share/temp/a 3./home/share/temp/test.py whose contents are #!/usr/bin/env python import os import sys print sys.version print os.uname() print os.path.realpath("/home/share/temp/../a.lnk") print os.path.abspath("/home/share/temp/../a.lnk") and I ran the python script on two different machines,but the version of python interpreters are the same,and both of them are 64 bits machine, but the result of os.path.realpath is different,one is -------------------------------------------------------- 2.3.4 (#1, Feb 2 2005, 11:44:13) [GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] ('Linux', 'tc-com-test00.tc.baidu.com', '2.6.9-52bs', '#2 SMP Fri Jan 26 13:34:38 CST 2007', 'x86_64') /home/share/a.lnk /home/share/a.lnk another is ----------------------------------------------------------- 2.3.4 (#1, Dec 11 2007, 05:28:55) [GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] ('Linux', 'tc-ecom-dev00.tc.baidu.com', '2.6.9-52bs', '#2 SMP Fri Jan 26 13:34:38 CST 2007', 'x86_64') /home/share/temp/temp/a /home/share/a.lnk But obviously the first one os.path.realpath(...) should be /home/share/temp/a instead of /home/share/a.lnk and the second on os.path.realpath(...) should also be /home/share/temp/a instaed of /home/share/temp/temp/a ---------- components: Library (Lib) messages: 77719 nosy: dirlt severity: normal status: open title: os.path.realpath() get the wrong result type: behavior versions: Python 2.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 10:14:52 2008 From: report at bugs.python.org (Mark Summerfield) Date: Sat, 13 Dec 2008 09:14:52 +0000 Subject: [issue4630] IDLE no longer respects .Xdefaults insertOffTime In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za> Message-ID: <1229159692.27.0.53321633186.issue4630@psf.upfronthosting.co.za> Mark Summerfield added the comment: Although I stand by my criticism of IDLE not offering the option of switching off cursor blink, I've now discovered that the problem was with Fedora 10 no longer executing xrdb .Xdefaults; once I added that line to my .bash_profile the cursor blinking stopped. However, that is no help to people using Windows for whom the only solution is to manually edit the EditorWindow.py file every time they install a new version of Python. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 10:27:12 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 09:27:12 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229160432.18.0.983141755998.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: About the name: Java's Bignum has a 'significantBits' method, which apparently returns the position of the MSB (i.e., numbits - 1). GMP has mpz_sizeinbase; mpz_sizeinbase(n, 2) is almost the same as numbits, except that mpz_sizeinbase(0, 2) is 1, not 0. Mathematica has BitLength. I quite like this. Googling for 'ilog2' returns a good few relevant hits; again, this is really numbits - 1, not numbits. How about n.bitlength? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 10:58:54 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 09:58:54 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229162334.6.0.462529428705.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Perhaps n.bit_length() with an underscore. The name sounds good to my ear and sensibilities. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 11:35:40 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 10:35:40 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229164540.46.0.40540777223.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Perhaps n.bit_length() with an underscore. I thought I recalled Guido having a preference for float.fromhex over float.from_hex when that got implemented. But either spelling seems good to me. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 11:44:10 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 10:44:10 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229165050.83.0.00249003124902.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I thought I recalled Guido having a preference for float.fromhex over Can't find anything to back this up. It looks like I'm just making this up. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 11:53:38 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 10:53:38 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229165618.52.0.84946910742.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It was probably true. The issue is how well the words self-separate visually and whether an underscore would create a detrimental mental pause. So fromkeys() and fromhex() read fine and would feel awkward with an underscore. But bitlength causes me a mental double-take when my mind searches for the word separation. It that case, PEP 8 suggests that an underscore be added for clarity. This is probably why Mathematica chose BitLength in titlecase instead of Bitlength. Logic aside, bit_length() just looks and feels better to me. Did you look at the O(lg n) algorithm yet? Any thoughts? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 12:20:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 11:20:19 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229167219.09.0.273966928079.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Did you look at the O(lg n) algorithm yet? Any thoughts? So there are two places this could be applied: the int_numbits method and _PyLong_NumBits. I'd be quite surprised if this offered any noticeable speedup in either case. Might be worth a try, though---I'll see if I can get some timings. For int_numbits, it would have to be implemented in a way that works for 32-bit and 64-bit C longs. And if it also just happens to work for other sizes, that would be good, too. I'd probably try something like: while (v > 0xFFFFFFFF) { bitcount += 32; v >>= 32; } before doing a 32-bit bitcount on what's left. On a 32-bit machine, the whole while loop should just be optimized away to nothing. Similarly, in _PyLong_NumBits it would be good if it could be implemented in a way that doesn't have to change if/when PyLong_SHIFT is changed. I prefer the second variant given (the non-branching version). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 13:38:25 2008 From: report at bugs.python.org (Retro) Date: Sat, 13 Dec 2008 12:38:25 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229171905.93.0.134142297177.issue4649@psf.upfronthosting.co.za> Retro added the comment: What is recommended in PEP 8, you are engouraged to follow that; not you as a Python coder but you as a member of the Python community where PEP 8 is the coding style specification. Python's built-in modules have such a lovely coding style because they all follow PEP 8. Why must the documentation be an exception not to follow PEP 8? Is there a technical reason? And the lack of space is not an issue. PEP 8 makes it clear to "use spaces around arithmetic operators" and then it gives some examples what is acceptable and what is not. Let us look at this again, shall we? Yes: i = i + 1 No: i=i+1 Let us convert this into our version from the example code: Yes: a, b = b, a + b No: a,b=b,a+b Only the a+b part is not written according to PEP 8. Python beginners don't start learning the language by first reading PEP 8. They don't even know it exists; and since they are beginners, talking about the coding style is too soon. What they do first is read the Python tutorial and they look at how code is written in the tutorial and get used to that. And so if the code is badly written there, they will also write bad code (bad as in 'with a bad coding style'). So we must set an example for Python beginners (and also other people) to write good-coding-style code. So my point is that people won't need to read PEP 8 if that is applied into the documentation (especially the tutorial); they'll just look at some example code and know how to write code. Please fix those things like a+b to a + b and n//x to n // x. I have added mister van Rossum into this issue report, because I think we need a BDFL opinion. What do you think, mister van Rossum, about this? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:10:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 13:10:26 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229173826.77.0.369626353113.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Three files: (1) bit_length7.patch just does the numbits->bit_length renaming; otherwise it's the same as numbits-6b.patch. (2) bit_length7_opt.patch uses the fast bitcount method that Raymond pointed out. (3) bit_length_pybench.patch adds a test for bit_length to pybench. On my system (OS X 10.5.5/Core 2 Duo), on a 32-bit non-debug build of the trunk, pybench is showing me a 4-5% speedup for the optimized version. (I also tried a version that uses gcc's __builtin_clzl function; this was around 10% faster than the basic version, but of course it's not portable.) Added file: http://bugs.python.org/file12336/bit_length7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:11:10 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 13:11:10 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229173870.49.0.310717996722.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Added file: http://bugs.python.org/file12337/bit_length7_opt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:11:20 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 13:11:20 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229173880.49.0.836561816066.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Added file: http://bugs.python.org/file12338/bit_length_pybench.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:21:28 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 13:21:28 +0000 Subject: [issue4469] CVE-2008-5031 multiple integer overflows In-Reply-To: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za> Message-ID: <1229174488.33.0.477551736973.issue4469@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Backported r55839 and r61350, as r67726 ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:58:29 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 13:58:29 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229176709.35.0.287039889739.issue3439@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, I don't think bit_length() warrants a specific test which will slow down the whole pybench suite. pybench tracks interpreter speed for common and generally useful operations, while I think bit_length() is only a niche method. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:08:24 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:08:24 +0000 Subject: [issue4446] Distutils Metadata Documentation Missing "platforms" Keyword In-Reply-To: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za> Message-ID: <1229177304.79.0.149190044901.issue4446@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed for 2.5 as r67731; integration into the other branches still needs to happen. ---------- assignee: loewis -> georg.brandl priority: release blocker -> normal versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:14:24 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:14:24 +0000 Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11 In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za> Message-ID: <1229177664.75.0.282229846104.issue4368@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r67732. ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:15:40 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:15:40 +0000 Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1229177740.86.0.518707877415.issue4303@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As the ARM buildbot is still down, we have no way of analysing or fixing this problem, so I'm closing this as "won't fix". ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:36:31 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:36:31 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1229178991.21.0.964759596062.issue4228@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed (along with a test case) as r67733, in the 2.5 branch. Porting to the other branches still needs to happen. Armin, if you want to make these changes, please go ahead. ---------- priority: release blocker -> normal resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:37:11 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:37:11 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1229179031.89.0.2571041441.issue4228@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: normal -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:44:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:44:14 +0000 Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386 In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za> Message-ID: <1229179454.75.0.0881707941502.issue3863@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Backported to 2.5 as r67734. ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:49:44 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:49:44 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1229179784.89.0.622277457168.issue3248@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Committed for 2.5 as r67735. It still needs to be applied to the other branches. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:54:58 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 14:54:58 +0000 Subject: [issue4071] ntpath.abspath fails for long str paths In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za> Message-ID: <1229180098.53.0.146576942576.issue4071@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As it is apparently not clear what change exactly needs to be applied to 2.5, I'm declaring that this fix will not be backported. I would appreciate if somebody could summarize what still needs to be done, or (if nothing needs to be done), close this issue. ---------- priority: release blocker -> normal versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:55:49 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 14:55:49 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229180149.82.0.541676092285.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Well, I don't think bit_length() warrants a specific test which will > slow down the whole pybench suite. Me neither. It's a temporary patch to pybench, to establish whether it's worth applying optimizations to bit_length. I didn't intend that it should be applied to the trunk. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:00:37 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:00:37 +0000 Subject: [issue1683] Thread local storage and PyGILState_* mucked up by os.fork() In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za> Message-ID: <1229180437.0.0.325614375032.issue1683@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Committed fork-thread-patch-2 as r67736 into 2.5 branch. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:03:36 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:03:36 +0000 Subject: [issue2996] IDLE "find in files" output not formatted optimally In-Reply-To: <1212008945.94.0.774872087064.issue2996@psf.upfronthosting.co.za> Message-ID: <1229180616.12.0.644213909374.issue2996@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can't reproduce the problem. It works fine for me. ---------- nosy: +loewis priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:03:54 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 15:03:54 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229180634.07.0.575762220265.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Slightly improved optimized version. Added file: http://bugs.python.org/file12339/bit_length7_opt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:04:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 15:04:08 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229180648.05.0.278014595279.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12337/bit_length7_opt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:07:03 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 15:07:03 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229180823.67.0.719758051206.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Added another test to pybench; it makes sense to consider cases where the input n is uniformly distributed in [0, 2**31) as well as cases where the output n.bit_length() is uniformly distributed in [0, 32). Added file: http://bugs.python.org/file12340/bit_length_pybench.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:07:21 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:07:21 +0000 Subject: [issue4342] (Tkinter) Please backport these In-Reply-To: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za> Message-ID: <1229180841.12.0.197685116713.issue4342@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have backported r59654 as r67737. As indicated, the other patches are not suitable for backporting. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:07:23 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 15:07:23 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229180843.82.0.485424801923.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12338/bit_length_pybench.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:08:33 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 15:08:33 +0000 Subject: [issue3106] speedup some comparisons In-Reply-To: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za> Message-ID: <1229180913.94.0.963227199765.issue3106@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a new patch without any dispatch shortcut in ceval.c, just optimizations in unicodeobject.c and longobject.c. Net result on pybench: Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- CompareFloats: 166ms 170ms -2.3% 169ms 174ms -2.8% CompareFloatsIntegers: 230ms 231ms -0.7% 233ms 231ms +0.8% CompareIntegers: 247ms 270ms -8.7% 248ms 272ms -9.0% CompareInternedStrings: 196ms 254ms -22.7% 197ms 255ms -22.7% CompareLongs: 143ms 158ms -9.0% 143ms 158ms -9.3% CompareStrings: 156ms 168ms -7.4% 157ms 169ms -7.2% ------------------------------------------------------------------------------- Totals: 1139ms 1252ms -9.1% 1148ms 1260ms -8.9% The patch seems fairly uncontroversial to me, I'll commit it soon if there's no opposition. Added file: http://bugs.python.org/file12341/cmps5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:11:55 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:11:55 +0000 Subject: [issue3767] tkColorChooser may fail if no color is selected In-Reply-To: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za> Message-ID: <1229181115.71.0.651458357183.issue3767@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed tkColorChooser.diff as r67738 in the 2.5 branch. Applying this to the other branches still needs to be done. ---------- assignee: -> loewis nosy: +loewis priority: release blocker -> deferred blocker resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:16:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:16:12 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229181372.59.0.821242518166.issue1040026@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Committed os_times5.patch into 2.5 branch as r67739 Applying this to the other branches still needs to be done. ---------- assignee: gregory.p.smith -> loewis priority: release blocker -> deferred blocker resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:18:09 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:18:09 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229181489.74.0.422132757916.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Removed file: http://bugs.python.org/file9514/os_times2.PATCH _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:18:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:18:13 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229181493.63.0.95322559076.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Removed file: http://bugs.python.org/file9518/os_times3.PATCH _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:18:17 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:18:17 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229181497.52.0.220933456041.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Removed file: http://bugs.python.org/file9541/posixmodule.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:18:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:18:20 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229181500.87.0.501099144139.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Removed file: http://bugs.python.org/file9542/test_posix5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:35:30 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 15:35:30 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229182530.86.0.839512898967.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: I think I've found the happy medium: bit_length7_opt2.patch achieves nearly the same performance gains as bit_length7_opt.patch (around 7% for uniformly-distributed inputs, 3.5% for uniformly-distributed outputs), but is much more straightforward and readable. It's pretty much what Raymond suggested in the first place, plus a table lookup. Added file: http://bugs.python.org/file12342/bit_length7_opt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:37:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 15:37:39 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1229182659.35.0.942078535487.issue1706039@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed into the 2.5 branch as r67740. This still needs to be applied to the other branches. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 17:03:52 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 16:03:52 +0000 Subject: [issue3106] speedup some comparisons In-Reply-To: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za> Message-ID: <1229184232.24.0.893827009484.issue3106@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If there's not a hurry, would like to review this a bit more when I get back early next week. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 17:05:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2008 16:05:13 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229184313.6.0.177236743578.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If there's not a hurry, would like to review this a bit more when I get back early next week. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 17:08:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 13 Dec 2008 16:08:33 +0000 Subject: [issue4649] Fix a+b to a + b In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za> Message-ID: <1229184513.65.0.380897833727.issue4649@psf.upfronthosting.co.za> Guido van Rossum added the comment: Retro, you are blowing this way out of proportion. Style guidelines are not absolute rules that must be followed at all cost, and there are always exceptions. You need to have a lot of experience before you can claim with certainty that a certain piece of code should or should not be formatted according to the style guidelines. (This is as opposed to the syntax of the language, which is an absolute set of rules where violations raise a SyntaxError.) In this case, the PEP never meant to say that all arithmetic operators have to be surrounded by spaces. That would make just as little sense as requiring no spaces. The words in the PEP cannot possibly approximate the set of heuristics I have in my mind for this purpose, and I don't think they have to. When I wrote PEP 8 (or actually its precursor), I was merely *suggesting* that certain uses of spaces look better than others. If you are interpreting this as requiring all examples needing to follow the literal style guide, well, Im sorry, but that's not how it was meant, and I am not willing to either change the examples (the specific one you quote looks just fine to me) or to edit the PEP to try and formulate a more complex rule. In my experience, the more baroque the rule the more arguments it elicits. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 17:11:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 13 Dec 2008 16:11:55 +0000 Subject: [issue4651] getopt need re-factor... In-Reply-To: <1229150849.35.0.710720272237.issue4651@psf.upfronthosting.co.za> Message-ID: <1229184715.27.0.652314828919.issue4651@psf.upfronthosting.co.za> Guido van Rossum added the comment: Don't open a new issue to point out that you just opened a new issue. About removing getopt.error: if it's in 3.0, it needs to stay or be properly deprecated. 3.1 has to be backwards compatible with 3.0 for sure. ---------- nosy: +gvanrossum resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 17:12:25 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 16:12:25 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229184745.48.0.640179181811.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12332/numbits-6b.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 17:14:31 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 16:14:31 +0000 Subject: [issue3106] speedup some comparisons In-Reply-To: <1229184232.24.0.893827009484.issue3106@psf.upfronthosting.co.za> Message-ID: <1229184843.8863.1.camel@localhost> Antoine Pitrou added the comment: > If there's not a hurry, would like to review this a bit more when I get > back early next week. No pb! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 17:44:32 2008 From: report at bugs.python.org (Fredrik Johansson) Date: Sat, 13 Dec 2008 16:44:32 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229186672.96.0.41904975894.issue3439@psf.upfronthosting.co.za> Fredrik Johansson added the comment: FYI, Brent & Zimmermann call this function nbits(n) in "Modern Computer Arithmetic": http://www.loria.fr/~zimmerma/mca/pub226.html I don't really care much about the name though. In the documentation, should "same value as ``x.bit_length``" not be "same value as ``x.bit_length()``"? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:03:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 17:03:07 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1229187787.13.0.5546498724.issue4574@psf.upfronthosting.co.za> Antoine Pitrou added the comment: A couple of suggestions: - if IncrementalNewlineDecoder gets an encoding argument, it can also instantiate the decoder itself; that way the API is a bit simpler - to encode '\r' without the BOM, you can e.g. use an incremental encoder and encode it twice: >>> enc = codecs.getincrementalencoder('utf16')('strict') >>> enc.encode('\r') b'\xff\xfe\r\x00' >>> enc.encode('\r') b'\r\x00' I think breaking the API can be ok since the original API is broken (witness this bug). There can even be a compatibility mode where we check whether `encoding` has an encode() method, and if it has, take it as the decoder object rather than the encoding name. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:50:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 17:50:58 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229190658.2.0.0826522587081.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > In the documentation, should "same value as ``x.bit_length``" not be > "same value as ``x.bit_length()``"? Yes, of course. Thanks! Added file: http://bugs.python.org/file12343/bit_length7_opt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:51:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 17:51:08 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229190668.1.0.902466388549.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12342/bit_length7_opt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:54:06 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 13 Dec 2008 17:54:06 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229190846.66.0.815935131742.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12339/bit_length7_opt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 19:13:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 18:13:32 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1229192012.9.0.297291000718.issue4574@psf.upfronthosting.co.za> Changes by Antoine Pitrou : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 19:14:08 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 18:14:08 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1229192048.34.0.872861347699.issue4574@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a simpler patch with a different approach and a lot of tests. The advantage is that it doesn't break the API. Added file: http://bugs.python.org/file12344/utf16_newlines.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 19:30:54 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 18:30:54 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1229193054.91.0.431522794067.issue4574@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new variant also removes the dangerous hack in getstate / setstate. Added file: http://bugs.python.org/file12345/utf16_newlines2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 19:34:51 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 13 Dec 2008 18:34:51 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229193291.12.0.356013223731.issue1040026@psf.upfronthosting.co.za> Gregory P. Smith added the comment: should the unit test in test_posix5.patch have been removed? (regardless, its still on the bug tracker via the history links) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 19:52:45 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 13 Dec 2008 18:52:45 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1229194365.63.0.662574001931.issue4574@psf.upfronthosting.co.za> Gregory P. Smith added the comment: utf16_newlines2.patch looks good to me. This is a data corruption issue. If it is deferred for 3.0.1 it must be fixed in 3.0.2. +1 on putting this in 3.0.1. ---------- assignee: -> pitrou nosy: +gregory.p.smith priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 20:32:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 19:32:40 +0000 Subject: [issue3978] ZipFileExt.read() can be incredibly slow; patch included In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za> Message-ID: <1229196760.8.0.0320544187402.issue3978@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Attaching a cleanup of the proposed patch. The funny thing is that for me, both the unpatched and patched versions are as fast as the unzip binary. Added file: http://bugs.python.org/file12346/zipperf.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 20:49:49 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 19:49:49 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229197789.91.0.433201395172.issue4561@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Christian, by benchmarks I meant a measurement of text reading with and without the patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 21:58:41 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 20:58:41 +0000 Subject: [issue4583] segfault when mutating memoryview to array.array when array is resized In-Reply-To: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za> Message-ID: <1229201921.24.0.670379844518.issue4583@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch for the array module. ---------- keywords: +needs review, patch nosy: +pitrou priority: -> critical stage: -> patch review Added file: http://bugs.python.org/file12347/arraybuf.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 22:09:08 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 21:09:08 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229202548.7.0.546542263644.issue4653@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know Windows APIs but the pythonrun.c bug is genuine. ---------- nosy: +pitrou priority: -> high type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 22:11:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 21:11:12 +0000 Subject: [issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open() In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za> Message-ID: <1229202672.84.0.405110742884.issue4016@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: -> normal stage: -> patch review versions: +Python 3.1 -Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 22:26:36 2008 From: report at bugs.python.org (Johnny Lee) Date: Sat, 13 Dec 2008 21:26:36 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229203596.01.0.509650896916.issue4653@psf.upfronthosting.co.za> Johnny Lee added the comment: Here are the URLs to the MSDN documentation for CreateFileMapping and FormatMessage[A|W]: For CreateFileMapping(), from the Return Value section: "If the function fails, the return value is NULL. To get extended error information, call GetLastError." For FormatMessage[A|W]: nSize [in] If the FORMAT_MESSAGE_ALLOCATE_BUFFER flag is not set, this parameter specifies the size of the output buffer, in TCHARs. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 22:50:00 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 21:50:00 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229205000.91.0.285559124949.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Added file: http://bugs.python.org/file9542/test_posix5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 22:52:02 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Dec 2008 21:52:02 +0000 Subject: [issue1040026] os.times() is bogus In-Reply-To: <1229193291.12.0.356013223731.issue1040026@psf.upfronthosting.co.za> Message-ID: <49442E7F.9020403@v.loewis.de> Martin v. L?wis added the comment: > should the unit test in test_posix5.patch have been removed? I see. I wish that people would a) always provide complete patches in a single file, and b) delete files themselves that have been superceded by others. In any case, I have re-attached the file; thanks for pointing this out. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 00:06:12 2008 From: report at bugs.python.org (Johnny Lee) Date: Sat, 13 Dec 2008 23:06:12 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229209572.12.0.354930764566.issue4653@psf.upfronthosting.co.za> Johnny Lee added the comment: For the dynload_win.c typo, it's technically a possible buffer overflow, but you'd need to find an error that had an error message that's longer than 259 chars. In pythonrun.c, the if statements for fout and ferr and almost identical. Probably a good idea to convert the if-statement to a separate function and call that function with fout and then ferr. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 00:22:02 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 13 Dec 2008 23:22:02 +0000 Subject: [issue4163] textwrap wordsep_re Unicode In-Reply-To: <1224619523.16.0.79700210606.issue4163@psf.upfronthosting.co.za> Message-ID: <1229210522.7.0.334959922656.issue4163@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed in r67746 and r67747. Thanks for the patch! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 01:28:51 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 00:28:51 +0000 Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python integers. In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za> Message-ID: <1229214531.67.0.83294942127.issue4258@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Just tested the patch, here are some benchmarks: ./python -m timeit -s "a=100000000;b=777777" "a//b" -> 2.6: 0.253 usec per loop -> 3.1: 0.61 usec per loop -> 3.1 + patch: 0.331 usec per loop ./python -m timeit -s "a=100000000;b=777777" "a*b" -> 2.6: 0.431 usec per loop -> 3.1: 0.302 usec per loop -> 3.1 + patch: 0.225 usec per loop ./python -m timeit -s "a=100000000;b=777777" "a+b" -> 2.6: 0.173 usec per loop -> 3.1: 0.229 usec per loop -> 3.1 + patch: 0.217 usec per loop But it seems there are some outliers: ./python -m timeit -s "a=100000000**5+1;b=777777**3" "a//b" -> 2.6: 1.13 usec per loop -> 3.1: 1.12 usec per loop -> 3.1 + patch: 1.2 usec per loop ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 02:09:29 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 14 Dec 2008 01:09:29 +0000 Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python integers. In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za> Message-ID: <1229216969.57.0.834116065282.issue4258@psf.upfronthosting.co.za> STINNER Victor added the comment: I wrote a small benchmark tool dedicated to integer operations (+ - * / etc.): bench_int.py attached to issue4294. See also Message75715 and Message75719 for my benchmark results. Short sum up: 2^30 base helps a lot on 64 bits CPU (+26%) whereas the speedup is small (4%) on 32 bits CPU. But don't trust benchmarks :-p _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 02:31:05 2008 From: report at bugs.python.org (Jake) Date: Sun, 14 Dec 2008 01:31:05 +0000 Subject: [issue4655] setup.py should not use .pydistutils.cfg In-Reply-To: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za> Message-ID: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za> New submission from Jake : When installing python 2.6, I used: ./configure --prefix=/home/name/usr Installation was fine and everything was installed to: ~/usr/lib/python2.6 But the .so files were installed to: ~/usr/lib/python As ~/usr/lib/python was (no longer) declared in my PYTHONPATH, I ran into import issues. The problem was due to a forgotten file: ~/.pydistutils.cfg So this is clearly a user error, but I wonder if it is something which should be avoided at the setup.py level. When installing python, the installation locations are derived from the results of ./configure. When setup.py is eventually called, the installation locations can change. This seems undesirable. Would it be better if setup.py instructed distutils to ignore any configuration file so that the installation directories matched what was used by the rest of 'make install'? Related: http://bugs.python.org/issue1180 ---------- components: Installation messages: 77771 nosy: jah severity: normal status: open title: setup.py should not use .pydistutils.cfg type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 02:31:53 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 01:31:53 +0000 Subject: [issue4223] inspect.getsource doesn't work on functions imported from a zipfile In-Reply-To: <1225214386.69.0.0480331344152.issue4223@psf.upfronthosting.co.za> Message-ID: <1229218313.32.0.564653480021.issue4223@psf.upfronthosting.co.za> Nick Coghlan added the comment: After looking into this, I think Alexander is correct. There is no standard mapping between __file__ and __name__ and linecache is mistaken in assuming such a mapping exists for all importers (and is the same as the standard filesystem to name mapping to boot). In this particular case, it was the differences between the way the two relate for a package vs a normal module that was confusing linecache, but for more exotic cases the filesystem based rules that linecache was attempting to enforce may be completely irrelevant. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 02:37:40 2008 From: report at bugs.python.org (Jake) Date: Sun, 14 Dec 2008 01:37:40 +0000 Subject: [issue4655] during Python installation, setup.py should not use .pydistutils.cfg In-Reply-To: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za> Message-ID: <1229218660.76.0.406305428769.issue4655@psf.upfronthosting.co.za> Changes by Jake : ---------- title: setup.py should not use .pydistutils.cfg -> during Python installation, setup.py should not use .pydistutils.cfg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 02:46:33 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 01:46:33 +0000 Subject: [issue4523] logging module __init__ uses has_key In-Reply-To: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za> Message-ID: <1229219193.74.0.11069139951.issue4523@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r67748. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 02:48:55 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 01:48:55 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1229219335.13.0.272113193093.issue4512@psf.upfronthosting.co.za> Nick Coghlan added the comment: The spec get_filename is pretty simple: Return whatever __file__ would be set to if load_module() was called for this module. (runpy's problem is that it never actually loads the module in question, so it never gets the chance to interrogate __file__) _______________________________________ Python tracker _______________________________________ From jeremy at alum.mit.edu Sun Dec 14 03:54:52 2008 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Sat, 13 Dec 2008 21:54:52 -0500 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1229003638.88.0.787208793129.issue4631@psf.upfronthosting.co.za> References: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> <1229003638.88.0.787208793129.issue4631@psf.upfronthosting.co.za> Message-ID: Does the same thing happen with 2.6? Jeremy On Thu, Dec 11, 2008 at 8:53 AM, Jean-Paul Calderone wrote: > > Jean-Paul Calderone added the comment: > > The "f65" is the chunk length for the first chunk returned when > requesting that URL. A proxy could easily hide this by switching to a > different transfer encoding. > > ---------- > nosy: +exarkun > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > From report at bugs.python.org Sun Dec 14 03:54:55 2008 From: report at bugs.python.org (Jeremy Hylton) Date: Sun, 14 Dec 2008 02:54:55 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1229003638.88.0.787208793129.issue4631@psf.upfronthosting.co.za> Message-ID: Jeremy Hylton added the comment: Does the same thing happen with 2.6? Jeremy On Thu, Dec 11, 2008 at 8:53 AM, Jean-Paul Calderone wrote: > > Jean-Paul Calderone added the comment: > > The "f65" is the chunk length for the first chunk returned when > requesting that URL. A proxy could easily hide this by switching to a > different transfer encoding. > > ---------- > nosy: +exarkun > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ---------- nosy: +jhylton _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 05:06:20 2008 From: report at bugs.python.org (Matthew Cowles) Date: Sun, 14 Dec 2008 04:06:20 +0000 Subject: [issue4656] Python 3 tutorial has old information about dicts In-Reply-To: <1229227580.62.0.669575404687.issue4656@psf.upfronthosting.co.za> Message-ID: <1229227580.62.0.669575404687.issue4656@psf.upfronthosting.co.za> New submission from Matthew Cowles : [From a question sent to the python-help list.] In the Python 3 tutorial at: http://docs.python.org/3.0/tutorial/datastructures.html#dictionaries it says: The keys() method of a dictionary object returns a list of all the keys used in the dictionary, in arbitrary order if you want it sorted, just apply the sort() method to the list of keys But in What's New in Python 3.0 at: http://docs.python.org/3.0/whatsnew/3.0.html it says: dict methods dict.keys(), dict.items() and dict.values() return ?views? instead of lists. For example, this no longer works: k = d.keys(); k.sort(). Use k = sorted(d) instead I expect that it's just a matter of updating the tutorial. ---------- assignee: georg.brandl components: Documentation messages: 77776 nosy: georg.brandl, mdcowles severity: normal status: open title: Python 3 tutorial has old information about dicts versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 09:21:26 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 08:21:26 +0000 Subject: [issue4657] Doctest gets line numbers wrongs with <> in name In-Reply-To: <1229242886.47.0.883564319605.issue4657@psf.upfronthosting.co.za> Message-ID: <1229242886.47.0.883564319605.issue4657@psf.upfronthosting.co.za> New submission from Nick Coghlan : When writing the unit tests for running doctests from inside a zipfile, I initially had "" as the name being passed to the doctest.DocTestFinder.find method. With that name, the line numbers coming back for all of the examples were being incremented by 1 beyond what test_doctest expected (and hence my tests were failing). Changing the name to "anon" eliminated the errors. (Both "" also failed in the same fashion as "") I suspect there may be a problem with __LINECACHE_FILENAME_RE when "<" or ">" are embedded in the name used for the doctest execution. ---------- messages: 77777 nosy: ncoghlan severity: normal status: open title: Doctest gets line numbers wrongs with <> in name _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 10:44:53 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Sun, 14 Dec 2008 09:44:53 +0000 Subject: [issue4645] configparser DEFAULT In-Reply-To: <1229112616.18.0.592196405919.issue4645@psf.upfronthosting.co.za> Message-ID: <1229247893.91.0.212132106624.issue4645@psf.upfronthosting.co.za> Changes by Quentin Gallet-Gilles : ---------- versions: +Python 2.5.3 -Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:02:45 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Sun, 14 Dec 2008 10:02:45 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: Message-ID: <20081214100239.GA23823@chistera.yi.org> Adeodato Sim? added the comment: > Does the same thing happen with 2.6? No, I can't reproduce with 2.6.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:08:12 2008 From: report at bugs.python.org (Daniel Diniz) Date: Sun, 14 Dec 2008 10:08:12 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229249292.59.0.960701096969.issue4631@psf.upfronthosting.co.za> Daniel Diniz added the comment: Jeremy: no, it doesn't. Python 2.6.1+ (release26-maint:67716M, Dec 13 2008, 10:30:52) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 ~/release26-maint$ ./python -c "import urllib; print urllib.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readlines()[0]" >From mechanix at lucretia.debian.net Tue Dec 11 11:32:47 2001 ~/release26-maint$ ./python -c "from __future__ import unicode_literals; import urllib; print urllib.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readlines()[0]" >From mechanix at lucretia.debian.net Tue Dec 11 11:32:47 2001 FWIW, there are trailing spurious bytes too (note read() gives bytes, while readlines() both bytes and strings in 3.0): >>> import urllib.request; content = urllib.request.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').read() Python 3.1a0 (py3k:67702, Dec 11 2008, 11:09:14) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib.request >>> content = urllib.request.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').read() >>> content[-30:] b'PGP SIGNATURE-----\n\n\n\n\n\r\n0\r\n\r\n' >>> content[:10] b'f65\r\nFrom ' While in 2.6: >>> import urllib >>> content = urllib.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').read() >>> content[-30:] '---END PGP SIGNATURE-----\n\n\n\n\n' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:11:43 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Sun, 14 Dec 2008 10:11:43 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1229249292.59.0.960701096969.issue4631@psf.upfronthosting.co.za> Message-ID: <20081214101139.GA24102@chistera.yi.org> Adeodato Sim? added the comment: > FWIW, there are trailing spurious bytes too And in the middle of the document as well. Each time there's a chunk, I guess? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:20:46 2008 From: report at bugs.python.org (Resul Cetin) Date: Sun, 14 Dec 2008 10:20:46 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229250046.45.0.0104740698274.issue4631@psf.upfronthosting.co.za> Resul Cetin added the comment: I have the same problem with that code: (exchange USERNAME with your delicious username and PASSWORD with your delicious password): import urllib.request auth_handler = urllib.request.HTTPBasicAuthHandler() auth_handler.add_password('del.icio.us API', 'api.del.icio.us', USERNAME, PASSWORD) opener = urllib.request.build_opener(auth_handler) print(str(opener.open('https://api.del.icio.us/v1/posts/all').read(20), "utf-8")) And I don't use a proxy or anything like that. This makes python 3 completely unusable for me. And python 2.6 gives me what I want (the content of that virtual file) without any extra data in front or in the middle of the content. ---------- nosy: +ResulCetin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:24:36 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 10:24:36 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229250276.41.0.0278229181837.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Update both patches: (1) change PyLong_FromLong(ndigits-1) to PyLong_FromSsize_t(ndigits-1) in both patches (it's possible to have a 32-bit long and 64-bit Py_ssize_t), and (2) in the optimized patch, add the table lookup optimization for long_bit_length. Added file: http://bugs.python.org/file12348/bit_length7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:24:44 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 10:24:44 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229250284.55.0.860214448068.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12336/bit_length7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:25:09 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 10:25:09 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229250309.23.0.921874758076.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Added file: http://bugs.python.org/file12349/bit_length7_opt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:25:16 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 10:25:16 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229250316.91.0.0939660102591.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12343/bit_length7_opt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:56:42 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 10:56:42 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1229252202.05.0.550884671023.issue4197@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed for 2.7 in r67750. Will be ported to 2.6, 3.0 and 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:56:54 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 10:56:54 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za> Message-ID: <1229252214.0.0.0140384111398.issue4201@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed for 2.7 in r67750. Will be ported to 2.6, 3.0 and 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:57:24 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 10:57:24 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1229252244.15.0.541938894924.issue4512@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed for 2.7 in r67750. Will be ported to 2.6, 3.0 and 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:58:25 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 10:58:25 +0000 Subject: [issue4512] Add get_filename method to zipimport In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za> Message-ID: <1229252305.14.0.200831569045.issue4512@psf.upfronthosting.co.za> Nick Coghlan added the comment: Correction - added as _get_filename() in that revision. Documenting it and making it public (i.e. removing the underscore) is still to be done, and will only be done for 2.7/3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:59:02 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 10:59:02 +0000 Subject: [issue4082] __main__.__file__ not set correctly when -m switch gets __main__ from a zipfile In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za> Message-ID: <1229252342.95.0.874954204544.issue4082@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed for 2.7 in r67750. Will be ported to 2.6, 3.0 and 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:59:14 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 10:59:14 +0000 Subject: [issue4223] inspect.getsource doesn't work on functions imported from a zipfile In-Reply-To: <1225214386.69.0.0480331344152.issue4223@psf.upfronthosting.co.za> Message-ID: <1229252354.2.0.979939498613.issue4223@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed for 2.7 in r67750. Will be ported to 2.6, 3.0 and 3.1. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 12:32:04 2008 From: report at bugs.python.org (Daniel Diniz) Date: Sun, 14 Dec 2008 11:32:04 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229254324.09.0.869278155459.issue4631@psf.upfronthosting.co.za> Daniel Diniz added the comment: Took me a bit of Wiresharking to find this out, the problem is that we are asking for the page using HTTP 1.1 in 3.0. Here's a workaround patch for those who need it quick, I have yet to look at urllib to see what can be fixed there. --- Index: Lib/http/client.py =================================================================== --- Lib/http/client.py (revision 67716) +++ Lib/http/client.py (working copy) @@ -600,7 +600,7 @@ class HTTPConnection: _http_vsn = 11 - _http_vsn_str = 'HTTP/1.1' + _http_vsn_str = 'HTTP/1.0' response_class = HTTPResponse default_port = HTTP_PORT --- This is what we send in 2.5 and 3.0: GET /cgi-bin/bugreport.cgi?mbox=yes;bug=123456 HTTP/1.0 User-Agent: Python-urllib/1.17 GET /cgi-bin/bugreport.cgi?mbox=yes;bug=123456 HTTP/1.1 Accept-Encoding: identity User-Agent: Python-urllib/3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 12:57:41 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 11:57:41 +0000 Subject: [issue1734234] Fast path for unicodedata.normalize() Message-ID: <1229255861.17.0.995469914008.issue1734234@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a new patch against trunk, including the modified data files. All tests pass and I confirm a very healthy speed-up (~ 5x) when trying to a normalize an already normalized string. The slowdown for non-normalized strings is so small that it cannot be distinguished from measurement noise. Martin, do you think this can be committed? ---------- nosy: +loewis stage: -> patch review type: -> performance versions: +Python 2.7, Python 3.1 -Python 2.6 Added file: http://bugs.python.org/file12350/uninorm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:05:21 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 12:05:21 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229256321.22.0.490671426312.issue4631@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: -> critical type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:11:17 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 12:11:17 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1229256677.19.0.98931268437.issue4197@psf.upfronthosting.co.za> Nick Coghlan added the comment: Final revisions for fix: 2.7 = r67751 (there was a new test file missing from the initial checkin) 2.6 = r67752 3.1 = r67753 3.0 = r67754 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:11:38 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 12:11:38 +0000 Subject: [issue4201] Pdb cannot access source code in zipped packages. In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za> Message-ID: <1229256698.65.0.788365157421.issue4201@psf.upfronthosting.co.za> Nick Coghlan added the comment: Final revisions for fix: 2.7 = r67751 (there was a new test file missing from the initial checkin) 2.6 = r67752 3.1 = r67753 3.0 = r67754 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:11:52 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 12:11:52 +0000 Subject: [issue4082] __main__.__file__ not set correctly when -m switch gets __main__ from a zipfile In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za> Message-ID: <1229256712.06.0.479748949552.issue4082@psf.upfronthosting.co.za> Nick Coghlan added the comment: Final revisions for fix: 2.7 = r67751 (there was a new test file missing from the initial checkin) 2.6 = r67752 3.1 = r67753 3.0 = r67754 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:12:24 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 12:12:24 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229256744.47.0.82779316279.issue4631@psf.upfronthosting.co.za> Antoine Pitrou added the comment: IMO we should downgrade urlopen to HTTP 1.0 in 3.0.1. Implementing chunked encoding will come later if people are interested in doing it. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:12:42 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 14 Dec 2008 12:12:42 +0000 Subject: [issue4223] inspect.getsource doesn't work on functions imported from a zipfile In-Reply-To: <1225214386.69.0.0480331344152.issue4223@psf.upfronthosting.co.za> Message-ID: <1229256762.63.0.53065473264.issue4223@psf.upfronthosting.co.za> Nick Coghlan added the comment: Final revisions for fix: 2.7 = r67751 (there was a new test file missing from the initial checkin) 2.6 = r67752 3.1 = r67753 3.0 = r67754 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:17:18 2008 From: report at bugs.python.org (Daniel Diniz) Date: Sun, 14 Dec 2008 12:17:18 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229257038.45.0.364057050521.issue4631@psf.upfronthosting.co.za> Daniel Diniz added the comment: Clarifying the diagnosis, the offending spurious bytes are only present when we use 3.0's GET above. That's because urllib.request.HTTPHandler asks for a vanilla http.client.HTTPConnection, which uses HTTP 1.1. IIUC, either we change the request version back to 1.0 (attached patch) or correct the way the response is processed (is it at all?). I think HTTPSHandler will also suffer from this, perhaps [Fancy]URLopener too. [Antoine: cool, an edit conflict that agrees with what I was about to post :D] ---------- keywords: +patch Added file: http://bugs.python.org/file12351/urllib_bytes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:36:23 2008 From: report at bugs.python.org (Malte Helmert) Date: Sun, 14 Dec 2008 12:36:23 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229258183.92.0.117188204097.issue1040026@psf.upfronthosting.co.za> Malte Helmert added the comment: > I see. I wish that people would a) always provide complete patches in > a single file, and b) delete files themselves that have been > superceded by others. In any case, I have re-attached the file; > thanks for pointing this out. Regarding b), I did that as far as I could (i.e., deleted my own files that were superseded). I left the unit test as a separate file because I wasn't too sure if it would get incorporated -- it looks a bit flaky because it relies on timing issues, and it's also one of the longer-running tests as it spends (comparatively) a lot of time in a busy loop. I wouldn't be surprised if it breaks on some machines sometimes, especially ones with low clock granularity. Thanks for the comment though, I'll keep it in mind in the future. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:53:10 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 12:53:10 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1229259190.18.0.590228084832.issue3166@psf.upfronthosting.co.za> Mark Dickinson added the comment: Updated patch; cleanup of comments and slight refactoring of code. Int->float conversions are even a speck faster than the current code, for small inputs. (On my machine, on a Friday night, during a full moon. Your results may differ. :)) Also, retarget this for 2.7 and 3.1. ---------- versions: +Python 2.7, Python 3.1 -Python 2.6 Added file: http://bugs.python.org/file12352/long_as_double3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:53:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 12:53:15 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1229259195.3.0.820047725449.issue3166@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file10694/long_as_double.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 13:53:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 12:53:19 +0000 Subject: [issue3166] Make conversions from long to float correctly rounded. In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za> Message-ID: <1229259199.33.0.0281312146352.issue3166@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12320/long_as_double2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 15:59:26 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sun, 14 Dec 2008 14:59:26 +0000 Subject: [issue4071] ntpath.abspath fails for long str paths In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za> Message-ID: <1229266766.59.0.549061501458.issue4071@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: GetFullPathNameW may return the required buffer size (non-zero value) when buffer is too short. Before r67154, this case was treated as success, so there was possibility of access to uninitialized buffer woutbuf. Fortunately, GetFullPathNameW sets '\0' to woutbuf (this is undocumented behavior), so abspath() returned empty string instead of segmentation fault. But this is still potentially dangerous, so I fixed this by allocating required size buffer and calling GetFullPathNameW again. abspath() returns correct result for any long unicode path now. But original poster hopes abspath() should return correct result for any long both *str* and unicode path. For str, this issue is not solved yet. -- I'm skeptical abspath() should support longer path than MAX_PATH if ANSI version of Windows API cannot handle such path. Anyway, I won't use such long path. ;-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 16:09:59 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 15:09:59 +0000 Subject: [issue4656] Python 3 tutorial has old information about dicts In-Reply-To: <1229227580.62.0.669575404687.issue4656@psf.upfronthosting.co.za> Message-ID: <1229267399.6.0.17569470646.issue4656@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks! Fixed in r67755. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 16:25:08 2008 From: report at bugs.python.org (Bram Geron) Date: Sun, 14 Dec 2008 15:25:08 +0000 Subject: [issue4658] missing closing bracket in Functional Programming HOWTO In-Reply-To: <1229268308.32.0.937567337993.issue4658@psf.upfronthosting.co.za> Message-ID: <1229268308.32.0.937567337993.issue4658@psf.upfronthosting.co.za> New submission from Bram Geron : In the Functional Programming HOWTO -> Built-in functions -> sorted, the syntaxis code misses a closing square bracket just after `reverse=False`. ---------- assignee: georg.brandl components: Documentation messages: 77801 nosy: bgeron, georg.brandl severity: normal status: open title: missing closing bracket in Functional Programming HOWTO versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:11:54 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 16:11:54 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229271114.73.0.185491122861.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a simple patch implementing Martin's proposal with a few basic tweaks. Using Greg's script, we get: -> without patch: 1000000 2.64134001732 2000000 3.60712885857 3000000 5.40855813026 4000000 6.46308898926 5000000 8.65147781372 6000000 10.3949871063 7000000 12.1376650333 8000000 12.7046239376 9000000 15.4652290344 -> with patch: 1000000 2.692289114 2000000 1.91455483437 3000000 2.02900099754 4000000 1.72369813919 5000000 1.87697696686 6000000 2.08952093124 7000000 1.08168196678 8000000 2.32068109512 9000000 1.1202070713 -> with GC disabled: 1000000 1.6810901165 2000000 0.955595970154 3000000 0.959649085999 4000000 0.933673858643 5000000 0.954123973846 6000000 0.929254055023 7000000 0.901160001755 8000000 0.921751022339 9000000 0.894830942154 ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file12353/gctrigger.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:13:37 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Dec 2008 16:13:37 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229271217.78.0.831681885287.issue1040026@psf.upfronthosting.co.za> Guido van Rossum added the comment: [-gvanrossum] _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:13:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Dec 2008 16:13:55 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229271235.1.0.608627849731.issue1040026@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:25:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 16:25:12 +0000 Subject: [issue4659] compilation warning in Modules/zipimport.c In-Reply-To: <1229271912.51.0.683304692503.issue4659@psf.upfronthosting.co.za> Message-ID: <1229271912.51.0.683304692503.issue4659@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Probably harmless: ./Modules/zipimport.c: In function ?get_module_code?: ./Modules/zipimport.c:1132: warning: format ?%c? expects type ?int?, but argument 3 has type ?long int? ---------- components: Extension Modules messages: 77804 nosy: pitrou priority: low severity: normal status: open title: compilation warning in Modules/zipimport.c versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:32:46 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 14 Dec 2008 16:32:46 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1229256677.19.0.98931268437.issue4197@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: Nick, Your commit does not fix the line number reporting from doctest failures: $ ./python.exe testmodule.zip ********************************************************************** File "testmodule.zip/__main__.py", line ?, in __main__.c ... Note the '?' in the output. Did you miss the doctest.py changes in doctest-1.patch, or should I open a separate issue for the line number bug? There is also a problem of __main__.c which my patch does not address, but it is less important than the line number. On Sun, Dec 14, 2008 at 7:11 AM, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Final revisions for fix: > 2.7 = r67751 (there was a new test file missing from the initial checkin) > 2.6 = r67752 > 3.1 = r67753 > 3.0 = r67754 > > ---------- > resolution: -> fixed > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:48:02 2008 From: report at bugs.python.org (Brian) Date: Sun, 14 Dec 2008 16:48:02 +0000 Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za> Message-ID: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za> New submission from Brian : Despite carefully matching my get() and task_done() statements I would often trigger "raise ValueError('task_done() called too many times')" in my multiprocessing.JoinableQueue (multiprocessing/queues.py) Looking over the code (and a lot of debug logging), it appears that the issue arises from JoinableQueue.put() not being protected with a locking mechanism. A preemption after the first line allows other processes to resume without releasing the _unfinished_tasks semaphore. The simplest solution seems to be allowing task_done() to block while waiting to acquire the _unfinished_tasks semaphore. Replacing: if not self._unfinished_tasks.acquire(False): raise ValueError('task_done() called too many times') With simply: self._unfinished_tasks.acquire() This would however remove the error checking provided (given the many far more subtler error that can be made, I might argue it is of limited value). Alternately the JoinableQueue.put() method could be better protected. ---------- components: Library (Lib) messages: 77806 nosy: merrellb severity: normal status: open title: multiprocessing.JoinableQueue task_done() issue versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:54:21 2008 From: report at bugs.python.org (Brian) Date: Sun, 14 Dec 2008 16:54:21 +0000 Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za> Message-ID: <1229273661.75.0.0580172426283.issue4660@psf.upfronthosting.co.za> Changes by Brian : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:55:46 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Sun, 14 Dec 2008 16:55:46 +0000 Subject: [issue4661] email.parser: impossible to read messages encoded in a different encoding In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za> Message-ID: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za> New submission from Adeodato Sim? : Currently, email.parser/feedparser can only parse messages that come as a string, or from a file opened in text mode. Email messages, however, can contain 8bit characters in any encoding other than the local one (yet still be valid e-mails, of course), so I think a method is needed to have the parser be able to receive bytes. At the moment, and as far as I can see, it's not possible to parse some perfectly valid messages with python 3.0. I don't think it's appropriate to ask that files be opened with the proper encoding, and then for the parser to read them. First, it is not possible to know what encoding that would be without parsing the message. And second, a message could contain parts in different encoding, and many mailboxes with random messages most certainly do. Also, message objects will need a way to return a bytes repreentation, for the reasons explained above, and particularly if one wants to write back the message without modifying it. ---------- components: Library (Lib) messages: 77807 nosy: dato severity: normal status: open title: email.parser: impossible to read messages encoded in a different encoding versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 18:10:53 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 17:10:53 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1229274653.51.0.950462598625.issue4574@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed to py3k and release30-maint in r67760 and r67759. Needs backporting to 2.x. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 18:24:23 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 17:24:23 +0000 Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za> Message-ID: <1229275463.04.0.66359301478.issue4660@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> jnoller nosy: +jnoller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 18:24:43 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 17:24:43 +0000 Subject: [issue4661] email.parser: impossible to read messages encoded in a different encoding In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za> Message-ID: <1229275483.14.0.801611874275.issue4661@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> barry nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 18:26:17 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 17:26:17 +0000 Subject: [issue4658] missing closing bracket in Functional Programming HOWTO In-Reply-To: <1229268308.32.0.937567337993.issue4658@psf.upfronthosting.co.za> Message-ID: <1229275577.69.0.818049103769.issue4658@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67761. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 18:34:43 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Sun, 14 Dec 2008 17:34:43 +0000 Subject: [issue4662] posix module lacks several DeprecationWarning's In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za> Message-ID: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : posix module lacks DeprecationWarning for the functions listed below: tempnam, tmpfile, fdopen, getcwdu, popen, tmpnam All of these are absent in 3.0, so I think adding DeprecationWarning to all of them would be useful. Attaching a straight-forward patch against latest trunk checkout. ---------- files: posixmodule.patch keywords: patch messages: 77810 nosy: mishok13 severity: normal status: open title: posix module lacks several DeprecationWarning's versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file12354/posixmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 19:05:35 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 18:05:35 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229277935.97.0.308591583982.issue4575@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch (force_to_memory2.patch) that I'm hoping fixes the cmath test failures on Solaris 10/x86. Skip, could you give it a try? The patch isn't final: I need to look for more places where Py_FORCE_DOUBLE should be applied. But I'll wait to find out whether this really does fix the problem, first; I'm still just guessing about the cause. By the way, it looks like the problem with the original patch, on OS X, was that nothing in pymath.c is used in the Python *core*, so the symbols from pymath.o aren't compiled into the python.exe executable, and they're not available when loading modules. Rather than working out how to fix this, I just moved the definitions into Objects/floatobject.c instead. Added file: http://bugs.python.org/file12355/force_to_memory2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 19:07:21 2008 From: report at bugs.python.org (Adam Olsen) Date: Sun, 14 Dec 2008 18:07:21 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229278041.34.0.625813990913.issue4074@psf.upfronthosting.co.za> Adam Olsen added the comment: I didn't test it, but the patch looks okay to me. ---------- nosy: +Rhamphoryncus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 19:11:51 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 18:11:51 +0000 Subject: [issue4574] reading UTF16-encoded text file crashes if \r on 64-char boundary In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za> Message-ID: <1229278311.97.0.907075576942.issue4574@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Backported to trunk and 2.6.2 in r67762 and r67764. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 19:18:31 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 18:18:31 +0000 Subject: [issue4663] Increase TextIOWrapper._CHUNK_SIZE In-Reply-To: <1229278711.0.0.240635346547.issue4663@psf.upfronthosting.co.za> Message-ID: <1229278711.0.0.240635346547.issue4663@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Simply bumping TextIOWrapper._CHUNK_SIZE from 128 to 1024 yields some significant performance improvements. ./python -m timeit -s "f=open('LICENSE')" "f.seek(0)" "for line in f: pass" -> with 128: 6.21 msec per loop -> with 1024: 3.41 msec per loop ./python -m timeit -s "f=open('LICENSE')" "f.seek(0)" "while f.read(100): pass" -> with 128: 4.03 msec per loop -> with 1024: 1.25 msec per loop Is there any counter-indication to doing so? ---------- messages: 77814 nosy: christian.heimes, pitrou priority: high severity: normal status: open title: Increase TextIOWrapper._CHUNK_SIZE type: performance versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 20:07:21 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sun, 14 Dec 2008 19:07:21 +0000 Subject: [issue4664] import urlparse, cStringIO breaks In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> New submission from Lennart Regebro : If you have urlparse before cStringIO in an import line, 2to3 will not convert the cStringIO to io. However, reverse the order, and urlparse will not get translated. So this file: import urlparse, cStringIO import cStringIO, urlparse will with 2to3 return the following diff: --- test3.py (original) +++ test3.py (refactored) @@ -1,3 +1,3 @@ -import urlparse, cStringIO -import cStringIO, urlparse +import urllib.parse, cStringIO +import io, urlparse ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 77815 nosy: lregebro severity: normal status: open title: import urlparse, cStringIO breaks type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 20:20:15 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Dec 2008 19:20:15 +0000 Subject: [issue4664] fix_imports does not refactor "import urlparse, cStringIO" correctly In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229282415.58.0.176518851762.issue4664@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Sorry, I still cannot reproduce it. Could you attach your test file? Maybe it is some weird encoding bug. alex at helios:~$ 2to3 -f imports test.py --- test.py (original) +++ test.py (refactored) @@ -1,2 +1,2 @@ -import urlparse, cStringIO -import cStringIO, urlparse +import urllib.parse, io +import io, urllib.parse RefactoringTool: Files that need to be modified: RefactoringTool: test.py ---------- nosy: +alexandre.vassalotti title: import urlparse, cStringIO breaks -> fix_imports does not refactor "import urlparse, cStringIO" correctly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 20:37:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 14 Dec 2008 19:37:45 +0000 Subject: [issue4645] configparser DEFAULT In-Reply-To: <1229112616.18.0.592196405919.issue4645@psf.upfronthosting.co.za> Message-ID: <1229283465.08.0.54586407884.issue4645@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The release candidate for 2.5.3 has been made; this patch cannot be considered anymore. Closing as fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 20:48:29 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 14 Dec 2008 19:48:29 +0000 Subject: [issue1040026] os.times() is bogus In-Reply-To: <1229258183.92.0.117188204097.issue1040026@psf.upfronthosting.co.za> Message-ID: <4945630A.8000003@v.loewis.de> Martin v. L?wis added the comment: > I wouldn't be > surprised if it breaks on some machines sometimes, especially ones with > low clock granularity. Now that I look at the test, I see what you mean. I think I will reject it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 20:50:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 19:50:52 +0000 Subject: [issue4664] fix_imports does not refactor "import urlparse, cStringIO" correctly In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229284252.83.0.929931470684.issue4664@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's one which doesn't work correctly: $ 2to3 - RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: set_literal RefactoringTool: Skipping implicit fixer: ws_comma import cStringIO, HTMLParser --- (original) +++ (refactored) @@ -1,1 +1,1 @@ -import cStringIO, HTMLParser +import io, HTMLParser RefactoringTool: Files that need to be modified: RefactoringTool: This is because the fix_imports pattern catching one module per import statement. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 20:53:42 2008 From: report at bugs.python.org (xianyiteng) Date: Sun, 14 Dec 2008 19:53:42 +0000 Subject: [issue1759845] subprocess.call fails with unicode strings in command line Message-ID: <1229284422.28.0.138384517845.issue1759845@psf.upfronthosting.co.za> Changes by xianyiteng : ---------- nosy: +xianyiteng _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 21:09:31 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 14 Dec 2008 20:09:31 +0000 Subject: [issue4662] posix module lacks several DeprecationWarning's In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za> Message-ID: <1229285371.89.0.679360323702.issue4662@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't think a DeprecationWarning is appropriate. Instead, there could be a -3 warning. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 21:10:23 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 20:10:23 +0000 Subject: [issue4662] posix module lacks several DeprecationWarning's In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za> Message-ID: <1229285423.94.0.899282354704.issue4662@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Well, it's trivial to use PyErr_WarnPy3k in place of PyErr_Warn. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 21:41:30 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 14 Dec 2008 20:41:30 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229287290.48.0.531031781886.issue4575@psf.upfronthosting.co.za> Roumen Petrov added the comment: may be proposed patch break platforms that need specific "export" decoration ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 21:46:08 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Sun, 14 Dec 2008 20:46:08 +0000 Subject: [issue4662] posix module lacks several DeprecationWarning's In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za> Message-ID: <1229287568.02.0.34912221531.issue4662@psf.upfronthosting.co.za> Changes by Andrii V. Mishkovskyi : Removed file: http://bugs.python.org/file12354/posixmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 21:47:26 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Sun, 14 Dec 2008 20:47:26 +0000 Subject: [issue4662] posix module lacks several DeprecationWarning's In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za> Message-ID: <1229287646.42.0.17020914495.issue4662@psf.upfronthosting.co.za> Andrii V. Mishkovskyi added the comment: I've missed one simple thing -- posix.getcwdu has been renamed to posix.getcwd in 3.0, so adding Py3k deprecation warning to this function is not really needed. Instead a fix for this should be added to the list of 2to3 fixes. I've also fixed the warnings according to Martin's proposal and updated the patch. Added file: http://bugs.python.org/file12356/posixmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 21:54:09 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sun, 14 Dec 2008 20:54:09 +0000 Subject: [issue4664] fix_imports does not refactor "import urlparse, cStringIO" correctly In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229288049.27.0.064639872446.issue4664@psf.upfronthosting.co.za> Lennart Regebro added the comment: Heres my test file. Added file: http://bugs.python.org/file12357/test3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:06:58 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Dec 2008 21:06:58 +0000 Subject: [issue4664] fix_imports does not refactor "import urlparse, cStringIO" correctly In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229288818.77.0.751694102843.issue4664@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Benjamin, your example fails for a different reason--i.e. the fixer for HTMLParser is missing. Sorry Lennart, I still cannot reproduce it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:08:26 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 14 Dec 2008 21:08:26 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1229277935.97.0.308591583982.issue4575@psf.upfronthosting.co.za> Message-ID: <18757.30145.855355.473477@montanaro-dyndns-org.local> Skip Montanaro added the comment: Mark> Skip, could you give it a try? Works for me on Solaris 10/x86. Based on Roumen's comment I am preparing to try it on Mac OS X/x86 and Solaris 10/sparc. Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:11:05 2008 From: report at bugs.python.org (Lennart Regebro) Date: Sun, 14 Dec 2008 21:11:05 +0000 Subject: [issue4664] fix_imports does not refactor "import urlparse, cStringIO" correctly In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229289065.12.0.140519444193.issue4664@psf.upfronthosting.co.za> Lennart Regebro added the comment: What version are you running? Can you post the output? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:16:32 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 14 Dec 2008 21:16:32 +0000 Subject: [issue4665] Failure to compile trunk on Solaris10/SPARC using C++ compiler In-Reply-To: <18757.30636.523605.327524@montanaro-dyndns-org.local> Message-ID: <18757.30636.523605.327524@montanaro-dyndns-org.local> New submission from Skip Montanaro : I don't know if the Python source is supposed to be compilable with a C++ compiler or not, but I'm having trouble finding a C compiler on the Solaris10/SPARC machines at work. I decided to give a C++ compiler a whirl: /opt/gnu/bin/c++ -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I../Include -DPy_BUILD_CORE -o Parser/tokenizer.o ../Parser/tokenizer.c ../Parser/tokenizer.c: In function `char * PyTokenizer_RestoreEncoding(tok_state *, int, int *)': ../Parser/tokenizer.c:1614: ANSI C++ forbids implicit conversion from `void *' in assignment Now this turns out to be a very old compiler: % /opt/gnu/bin/c++ --version 2.95.3 Should Python be able to compile with this ancient GNU C++ compiler? Thx, Skip ---------- messages: 77828 nosy: skip.montanaro severity: normal status: open title: Failure to compile trunk on Solaris10/SPARC using C++ compiler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:20:49 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Dec 2008 21:20:49 +0000 Subject: [issue4665] Failure to compile trunk on Solaris10/SPARC using C++ compiler In-Reply-To: <18757.30636.523605.327524@montanaro-dyndns-org.local> Message-ID: <1229289649.4.0.266565828061.issue4665@psf.upfronthosting.co.za> Christian Heimes added the comment: Python should be compile-able with a C++ compiler. I'll test it on my system in a couple of minutes. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:22:36 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 14 Dec 2008 21:22:36 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229289756.52.0.0584952080978.issue4575@psf.upfronthosting.co.za> Roumen Petrov added the comment: I'm not sure that patch has to deal with "force to memory". FYI: when I port python trunk to mingw platform I encounter some inconsistency for isinf. My note about issue follow: - configure.in: ... dnl FIXME: For mingw "isinf" is a macro defined in and can't be dnl detected as function. Also PC/pyconfig.h define HAVE_ISINF but it is dnl useless since header define Py_IS_INFINITY as (!_finite(X) && !_isnan(X)) dnl Also in pymath.h is commented too how PC/pyconfig.h define _isinf. dnl NOTE: For mingw to keep compatibility with native build we define dnl Py_IS_INFINITY in pyport.h. ... - pyport.h #ifdef __MINGW32__ ... /*NOTE: mingw has isinf as macro defined in math.h. Since PC/pyconfig.h define Py_IS_INFINITY(X) that cover HAVE_ISINF here for Py_IS_INFINITY we define same as for native build. This makes HAVE_ISINF needless. Also see comments in configure.in and pymath.h. */ #define Py_IS_INFINITY(X) (!_finite(X) && !_isnan(X)) .... next lest see Py_IS_INFINITY in pymath.h .... #ifndef Py_IS_INFINITY #ifdef HAVE_ISINF #define Py_IS_INFINITY(X) isinf(X) #else #define Py_IS_INFINITY(X) ((X) && (X)*0.5 == (X)) #endif #endif .... Is the macro Py_IS_INFINITY correct if isinf is not detected by configure script ? Also I think too that problem is that we has to classify result after conversion to double. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:22:45 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Dec 2008 21:22:45 +0000 Subject: [issue4664] Regression fix_imports does not refactor multiple imports correctly In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229289765.73.0.679589709664.issue4664@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I got it. It is a regression from a previous version of 2to3's fix_imports. I was able to reproduce your problem using the sandbox's 2to3. And to answer your question, I still running an older RC release of Python 3.0. That explains why I couldn't reproduce the problem. $ python3.0 -c "import sys; print(sys.version)" 3.0rc2+ (py3k:67237, Nov 16 2008, 15:10:03) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] ---------- title: fix_imports does not refactor "import urlparse, cStringIO" correctly -> Regression fix_imports does not refactor multiple imports correctly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:26:38 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 14 Dec 2008 21:26:38 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229289998.93.0.272497799592.issue4575@psf.upfronthosting.co.za> Roumen Petrov added the comment: As Skip Montanaro report that work on ... may be macro from pymath.h has to be changed to force conversion to double. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:29:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Dec 2008 21:29:56 +0000 Subject: [issue4665] Failure to compile trunk on Solaris10/SPARC using C++ compiler In-Reply-To: <18757.30636.523605.327524@montanaro-dyndns-org.local> Message-ID: <1229290196.99.0.590879286572.issue4665@psf.upfronthosting.co.za> Christian Heimes added the comment: The trunk contains lots of implicit casts from void pointers that make the code incompatible with C++. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:30:52 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 14 Dec 2008 21:30:52 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229290252.93.0.526219251261.issue4575@psf.upfronthosting.co.za> Roumen Petrov added the comment: about "export" decoration it is find in then patch PyAPI_FUNC(double) . found it after second review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:31:37 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 14 Dec 2008 21:31:37 +0000 Subject: [issue4665] Failure to compile trunk on Solaris10/SPARC using C++ compiler In-Reply-To: <18757.30636.523605.327524@montanaro-dyndns-org.local> Message-ID: <1229290297.42.0.77951668113.issue4665@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I disagree. It's not a requirement that the Python source code is compilable as C++. Only the header files should be thus compilable. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:36:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Dec 2008 21:36:34 +0000 Subject: [issue4665] Failure to compile trunk on Solaris10/SPARC using C++ compiler In-Reply-To: <18757.30636.523605.327524@montanaro-dyndns-org.local> Message-ID: <1229290594.18.0.797346539049.issue4665@psf.upfronthosting.co.za> Christian Heimes added the comment: Ah, I was under the impression that Python must be compatible both C++ and C89 compilers. Do we have any means to test the C++ compatibility of the header files? Full C++ compatibility is one way to make sure the header files are compatible, too. *wink* I don't see harm in sprinkling explicit type casts over the C code, too. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:47:46 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 14 Dec 2008 21:47:46 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229291266.08.0.867060245527.issue4575@psf.upfronthosting.co.za> Roumen Petrov added the comment: The macro Py_IS_INFINITY don't work on linux. The test case(force-inf.c) is attached. The result don't depend from optimisation flag. isinf(x)=1 Py_IS_INFINITY(x)=0 Py_IS_INFINITY2(x)=1 isinf(x)=0 Py_IS_INFINITY(x)=0 Py_IS_INFINITY2(x)=0 Added file: http://bugs.python.org/file12358/force-inf.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:48:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 14 Dec 2008 21:48:48 +0000 Subject: [issue4665] Failure to compile trunk on Solaris10/SPARC using C++ compiler In-Reply-To: <1229290594.18.0.797346539049.issue4665@psf.upfronthosting.co.za> Message-ID: <49457F3D.3070500@v.loewis.de> Martin v. L?wis added the comment: > Do we have any means to test the C++ compatibility of the header files? No, we fix it when users report bugs (which typically happens very quickly after we made some). > Full C++ compatibility is one way to make sure the header files are > compatible, too. *wink* I don't see harm in sprinkling explicit type > casts over the C code, too. That requires discussion, I'm opposed to such a change: it adds unnecessary complication. In any case, such discussion would belong to python-dev. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:55:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2008 21:55:52 +0000 Subject: [issue4664] Regression fix_imports does not refactor multiple imports correctly In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za> Message-ID: <1229291752.02.0.636473113451.issue4664@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r67774. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 22:56:30 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 14 Dec 2008 21:56:30 +0000 Subject: [issue4666] test_bad_address in test_urllib2_localnet often fails In-Reply-To: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za> Message-ID: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This error is often seen on the buildbots (both py3k and trunk): ====================================================================== FAIL: test_bad_address (test.test_urllib2_localnet.TestUrlopen) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\test\test_urllib2_localnet.py", line 452, in test_bad_address "http://www.python.invalid./") AssertionError: IOError not raised by urlopen ---------- components: Tests messages: 77840 nosy: pitrou priority: high severity: normal status: open title: test_bad_address in test_urllib2_localnet often fails type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:00:57 2008 From: report at bugs.python.org (Jeremy Hylton) Date: Sun, 14 Dec 2008 22:00:57 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229292057.01.0.471456468301.issue4631@psf.upfronthosting.co.za> Changes by Jeremy Hylton : ---------- assignee: -> jhylton _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:03:12 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 14 Dec 2008 22:03:12 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229292192.76.0.483341003782.issue4575@psf.upfronthosting.co.za> Mark Dickinson added the comment: > The macro Py_IS_INFINITY don't work on linux. The test case(force-inf.c) > is attached. The result don't depend from optimisation flag. Thanks, Roumen. I rather suspected that Py_IS_INFINITY was dodgy this way. On the other hand, this is only a problem when Py_IS_INFINITY is applied to a *computed* result; most of the time Py_IS_INFINITY is being directly applied to the incoming argument to some function, so should be safe. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:47:13 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 14 Dec 2008 22:47:13 +0000 Subject: [issue4666] test_bad_address in test_urllib2_localnet often fails In-Reply-To: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za> Message-ID: <1229294833.91.0.255778197037.issue4666@psf.upfronthosting.co.za> Roumen Petrov added the comment: I confirm that following tests test_curses test_urllib2_localnet test_urllibnet fail if regression test run all test. All three tests succeed if I run them one by one. Version - trunk, os - linux. ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 00:39:04 2008 From: report at bugs.python.org (Santiago Gala) Date: Sun, 14 Dec 2008 23:39:04 +0000 Subject: [issue4667] Patch with a couple of 2.0isms in tutorial In-Reply-To: <1229297944.68.0.249112177574.issue4667@psf.upfronthosting.co.za> Message-ID: <1229297944.68.0.249112177574.issue4667@psf.upfronthosting.co.za> New submission from Santiago Gala : references to reload as builtin or dict.keys as returning a list, and the use of the .sort method, all gone in 3.X ---------- assignee: georg.brandl components: Documentation files: tutorial.patch keywords: patch messages: 77843 nosy: georg.brandl, sgala severity: normal status: open title: Patch with a couple of 2.0isms in tutorial versions: Python 3.0 Added file: http://bugs.python.org/file12359/tutorial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 00:49:28 2008 From: report at bugs.python.org (Santiago Gala) Date: Sun, 14 Dec 2008 23:49:28 +0000 Subject: [issue4668] examples in the functional howto are not consistent with 3.X behavior In-Reply-To: <1229298568.02.0.45850154168.issue4668@psf.upfronthosting.co.za> Message-ID: <1229298568.02.0.45850154168.issue4668@psf.upfronthosting.co.za> New submission from Santiago Gala : map and filter don't return lists anymore, so wrapping them in list() in the examples will make the real output consistent with what is seen in the doc. ---------- assignee: georg.brandl components: Documentation files: 0001-Make-examples-consistent-with-3.0.patch keywords: patch messages: 77844 nosy: georg.brandl, sgala severity: normal status: open title: examples in the functional howto are not consistent with 3.X behavior versions: Python 3.0 Added file: http://bugs.python.org/file12360/0001-Make-examples-consistent-with-3.0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 03:31:59 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 15 Dec 2008 02:31:59 +0000 Subject: [issue4657] Doctest gets line numbers wrongs with <> in name In-Reply-To: <1229242886.47.0.883564319605.issue4657@psf.upfronthosting.co.za> Message-ID: <1229308319.4.0.427800639798.issue4657@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 04:59:46 2008 From: report at bugs.python.org (Jeremy Hylton) Date: Mon, 15 Dec 2008 03:59:46 +0000 Subject: [issue3761] urllib.request and urllib.response cannot handle HTTP1.1 chunked encoding In-Reply-To: <1220389188.67.0.216867570009.issue3761@psf.upfronthosting.co.za> Message-ID: <1229313586.19.0.108941491252.issue3761@psf.upfronthosting.co.za> Jeremy Hylton added the comment: I'm sorry that I didn't notice this bug report in September! The chunked support does exist in the http package, but it doesn't work with urllib. Tracking in 4631. ---------- nosy: +jhylton resolution: -> duplicate status: open -> closed superseder: -> urlopen returns extra, spurious bytes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 05:01:48 2008 From: report at bugs.python.org (Jeremy Hylton) Date: Mon, 15 Dec 2008 04:01:48 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229313708.1.0.299105722702.issue4631@psf.upfronthosting.co.za> Jeremy Hylton added the comment: Brief update: The Python 2.x code works because readline() is provided by socket._fileobject. The Python 3.x code fails because it grabs the HTTPResponse.fp instance variable at the end of AbstractHTTPHandler.do_open. That method needs to pass the response to addinfourl(), but needs to have support for readline / readlines before it can do that. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:28:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 08:28:45 +0000 Subject: [issue4667] Patch with a couple of 2.0isms in tutorial In-Reply-To: <1229297944.68.0.249112177574.issue4667@psf.upfronthosting.co.za> Message-ID: <1229329725.01.0.409879806205.issue4667@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67782. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:29:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 08:29:40 +0000 Subject: [issue4668] examples in the functional howto are not consistent with 3.X behavior In-Reply-To: <1229298568.02.0.45850154168.issue4668@psf.upfronthosting.co.za> Message-ID: <1229329780.73.0.0770904386653.issue4668@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67783. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:29:44 2008 From: report at bugs.python.org (John Machin) Date: Mon, 15 Dec 2008 08:29:44 +0000 Subject: [issue4669] bytes,join and bytearray.join not in manual; help for bytes.join is wrong. In-Reply-To: <1229329784.58.0.84286765915.issue4669@psf.upfronthosting.co.za> Message-ID: <1229329784.58.0.84286765915.issue4669@psf.upfronthosting.co.za> New submission from John Machin : These methods are parallel to str.join, seem to work as expected, and have "help" entries. However there is nothing in the Library Reference Manual about them. >>> help(bytearray.join) Help on method_descriptor: join(...) B.join(iterable_of_bytes) -> bytearray Concatenate any number of bytes/bytearray objects, with B in between each pair, and return the result as a new bytearray. ### OK but could use an example. >>> help(bytes.join) Help on method_descriptor: join(...) B.join(iterable_of_bytes) -> bytes Concatenate any number of bytes objects, with B in between each pair. ### Above sentence should read "Concatenate any number of bytes/bytearray objects, with B in between each pair, and return the result as a new bytes object." Example: b'.'.join([b'ab', b'pq', b'rs']) -> b'ab.pq.rs'. ---------- assignee: georg.brandl components: Documentation messages: 77849 nosy: georg.brandl, sjmachin severity: normal status: open title: bytes,join and bytearray.join not in manual; help for bytes.join is wrong. versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:34:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 08:34:07 +0000 Subject: [issue4446] Distutils Metadata Documentation Missing "platforms" Keyword In-Reply-To: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za> Message-ID: <1229330047.7.0.0683516784284.issue4446@psf.upfronthosting.co.za> Georg Brandl added the comment: Done in r67784. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:36:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 08:36:26 +0000 Subject: [issue4611] Small error in "Extending Python with C or C++" In-Reply-To: <1228836951.42.0.539810823139.issue4611@psf.upfronthosting.co.za> Message-ID: <1229330186.12.0.810557021673.issue4611@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67785. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:50:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 08:50:02 +0000 Subject: [issue4603] 3.0 document tab interpretation change In-Reply-To: <1228777550.97.0.72005547671.issue4603@psf.upfronthosting.co.za> Message-ID: <1229331002.36.0.622295320561.issue4603@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67786. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:56:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 08:56:18 +0000 Subject: [issue4595] new types example is out of date In-Reply-To: <1228753599.51.0.736503605174.issue4595@psf.upfronthosting.co.za> Message-ID: <1229331378.83.0.355415857158.issue4595@psf.upfronthosting.co.za> Georg Brandl added the comment: Already fixed in SVN. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:59:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 08:59:19 +0000 Subject: [issue4578] compiler: -3 warnings In-Reply-To: <1228671347.68.0.444266504353.issue4578@psf.upfronthosting.co.za> Message-ID: <1229331559.36.0.265167865819.issue4578@psf.upfronthosting.co.za> Georg Brandl added the comment: OK, since it doesn't do any damage I've applied your patch in r67787. ---------- resolution: wont fix -> fixed status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 10:08:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 09:08:07 +0000 Subject: [issue4568] Improved optparse "varargs" callback example In-Reply-To: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za> Message-ID: <1229332086.96.0.441848152998.issue4568@psf.upfronthosting.co.za> Georg Brandl added the comment: I've reformatted and rewritten your patch a bit and applied it as r67788. Thanks! ---------- resolution: -> accepted status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 10:29:57 2008 From: report at bugs.python.org (Krzysztof Szawala) Date: Mon, 15 Dec 2008 09:29:57 +0000 Subject: [issue4640] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za> Message-ID: <1229333397.1.0.674137866085.issue4640@psf.upfronthosting.co.za> Krzysztof Szawala added the comment: As I mentionetd, the problem occurs with Python 2.5 (I won't be switching to Python 3). The only perspective for me to upgrade is Python 2.6, but as I can see the problem applies to 2.6 as well. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 11:29:13 2008 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 15 Dec 2008 10:29:13 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1229336953.27.0.720293466507.issue4197@psf.upfronthosting.co.za> Nick Coghlan added the comment: Re-opening, pending development of a fully passing test specifically for the __main__.py in zipfile case. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 12:05:55 2008 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 15 Dec 2008 11:05:55 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1229339155.18.0.681160643445.issue4197@psf.upfronthosting.co.za> Nick Coghlan added the comment: I have a test case locally that demonstrates both the missing line number in the __main__.py from a zipfile case, as well as the display of main.c as the filename (the latter is not specific to the zipfile case - it also happens for a normal main module). It still seems to me that there is something going wrong at a deeper level for doctest to be getting the "in main.c" part wrong. I want to get to the bottom of that before working around the problem at the line number lookup stage. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 12:28:49 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Mon, 15 Dec 2008 11:28:49 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229340529.7.0.74229127499.issue1673409@psf.upfronthosting.co.za> Sebastian Rittau added the comment: A timedelta.toseconds method (or equivalent) makes no sense. The number of seconds in a day is not fixed (due to leap seconds) and relying on such a method would introduce subtle bugs. The only way to find out the number of seconds in a range of dates is if you have a concrete date range. ---------- nosy: +srittau _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 12:49:52 2008 From: report at bugs.python.org (Damien Miller) Date: Mon, 15 Dec 2008 11:49:52 +0000 Subject: [issue4670] setup.py exception when db_setup_debug = True In-Reply-To: <1229341792.75.0.0111494669008.issue4670@psf.upfronthosting.co.za> Message-ID: <1229341792.75.0.0111494669008.issue4670@psf.upfronthosting.co.za> New submission from Damien Miller : Hi, I receive the following exception when trying to build with db_setup_debug = True in setup.py. db_ver is not initialised in this path, except by accident so I think the obvious solution of - if db_setup_debug: print "db.h: unsupported version", db _ver, "in", d + if db_setup_debug: print "db.h: no version in", d Is the correct fix. running build running build_ext db: looking for db.h in ./db.h db: looking for db.h in Include/db.h db: looking for db.h in ./Include/db.h db: looking for db.h in /usr/local/include/db.h db: looking for db.h in /usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Include/db.h db: looking for db.h in /usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/db.h db: looking for db.h in /usr/include/db.h db.h: unsupported version Traceback (most recent call last): File "./setup.py", line 1543, in main() File "./setup.py", line 1538, in main scripts = [] File "/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/command/build_ext.py", line 290, in run self.build_extensions() File "./setup.py", line 97, in build_extensions self.detect_modules() File "./setup.py", line 700, in detect_modules if db_setup_debug: print "db.h: unsupported version", db_ver, "in", d UnboundLocalError: local variable 'db_ver' referenced before assignment ---------- components: Build messages: 77860 nosy: djmdjm severity: normal status: open title: setup.py exception when db_setup_debug = True type: compile error versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:03:13 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2008 12:03:13 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229342593.33.0.5028608851.issue1673409@psf.upfronthosting.co.za> STINNER Victor added the comment: > The number of seconds in a day is not fixed (due to leap seconds) POSIX timestamp doesn't count leap seconds. It looks like the datetime module is not aware of the leap seconds: >>> print datetime.datetime(2006, 1, 1) - datetime.datetime(2005, 12, 31) 1 day, 0:00:00 About my method: I finally prefer datetime/datetime or datetime//datetime instead of a toseconds() method. And to convert a timestamp to a timestamp: see my patch attached to issue #2736. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:03:25 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2008 12:03:25 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229342605.9.0.520448524481.issue1673409@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file11919/timedelta_toseconds_float.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:04:40 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2008 12:04:40 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229342680.13.0.397905623543.issue1673409@psf.upfronthosting.co.za> STINNER Victor added the comment: I removed my ".toseconds() method" patch because I prefer division. See issue #2706 for divison, divmod, etc. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:09:36 2008 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 15 Dec 2008 12:09:36 +0000 Subject: [issue4197] Doctest module does not work with zipped packages In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za> Message-ID: <1229342976.23.0.572178178354.issue4197@psf.upfronthosting.co.za> Nick Coghlan added the comment: It turns out you were pretty close to pinpointing the problem in doctest, but didn't quite manage to identify which step was going wrong. The problem was actually that even after __file__ was being set correctly, the call to linecache.getlines wasn't being given the __loader__ access it needed in order to retrieve the source code from inside the zipfile. The __main__.c thing turned out just to be a red herring caused by the choice of class name in the test code (I changed it to be __main__.Test for the checked in unit test). Checkin versions: 2.7 = r67790 2.6 = r67791 3.1 = r67792 3.0 = r67793 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:11:18 2008 From: report at bugs.python.org (Carwyn Edwards) Date: Mon, 15 Dec 2008 12:11:18 +0000 Subject: [issue4627] Add Mac OS X Disk Images to Python.org homepage In-Reply-To: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za> Message-ID: <1229343078.3.0.517994804095.issue4627@psf.upfronthosting.co.za> Carwyn Edwards added the comment: Just to note that issue 4017 is related to this. ---------- nosy: +carwyn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:57:25 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 12:57:25 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229345845.1.0.906054924123.issue1673409@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I also think totimestamp() on datetime objects would be useful, I've missed it myself a couple of times. The return value should be similar to that of time.time(), i.e. a float. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 14:05:00 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 13:05:00 +0000 Subject: [issue4666] test_bad_address in test_urllib2_localnet often fails In-Reply-To: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za> Message-ID: <1229346300.63.0.384529982909.issue4666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I tried a fix (see r67779, r67777 in trunk) and it seems to work. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 14:14:12 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Mon, 15 Dec 2008 13:14:12 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229346852.46.0.0446612434358.issue1673409@psf.upfronthosting.co.za> Sebastian Rittau added the comment: Leap second handling is usually configurable. Default on Debian Linux (but similar on RHEL and SuSE): >>> int(date(1994,1,1).strftime("%s")) - int(date(1993,1,1).strftime("%s")) 31536000 After doing "cp /usr/share/zoneinfo/right/Europe/Berlin /etc/localtime": >>> int(date(1994,1,1).strftime("%s")) - int(date(1993,1,1).strftime("%s")) 31536001 Also, NTP servers usually get this right. I don't think, Python should promote a wrong date handling by default, even if it's convenient. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 14:15:47 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2008 13:15:47 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229346947.85.0.0746038391436.issue1673409@psf.upfronthosting.co.za> STINNER Victor added the comment: > (...) totimestamp() (...) return value should be similar > to that of time.time(), i.e. a float float is a source of many problems (rounding problems), especially for huge values: float is unable to store correctly microseconds for big values: see msg75426. A simple tuple (int, int) is simple and there is no rounding/float limit. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 15:18:44 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 14:18:44 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229350724.8.0.821454996458.issue1673409@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What you say is "with 99500 days or more, the microsecond error is bigger than 90%". It means that with epoch starting at 1970, you can still return timestamps with a 1-2 microsecond accuracy for the year 2242. Additional precision would be overkill. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 15:26:28 2008 From: report at bugs.python.org (John Shue) Date: Mon, 15 Dec 2008 14:26:28 +0000 Subject: [issue4566] 2.6.1 breaks many applications that embed Python on Windows In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za> Message-ID: <1229351188.88.0.111921009338.issue4566@psf.upfronthosting.co.za> Changes by John Shue : ---------- nosy: +johnshue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 15:41:26 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 15 Dec 2008 14:41:26 +0000 Subject: [issue3106] speedup some comparisons In-Reply-To: <1229180913.94.0.963227199765.issue3106@psf.upfronthosting.co.za> Message-ID: <49466C92.4060409@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-13 16:08, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > Here is a new patch without any dispatch shortcut in ceval.c, just > optimizations in unicodeobject.c and longobject.c. Net result on pybench: > > Test minimum run-time average run-time > this other diff this other > diff > ------------------------------------------------------------------------------- > CompareFloats: 166ms 170ms -2.3% 169ms 174ms > -2.8% > CompareFloatsIntegers: 230ms 231ms -0.7% 233ms 231ms > +0.8% > CompareIntegers: 247ms 270ms -8.7% 248ms 272ms > -9.0% > CompareInternedStrings: 196ms 254ms -22.7% 197ms 255ms > -22.7% > CompareLongs: 143ms 158ms -9.0% 143ms 158ms > -9.3% > CompareStrings: 156ms 168ms -7.4% 157ms 169ms > -7.2% > ------------------------------------------------------------------------------- > Totals: 1139ms 1252ms -9.1% 1148ms 1260ms > -8.9% > > > The patch seems fairly uncontroversial to me, I'll commit it soon if > there's no opposition. Why have you removed the complete error handling section in PyUnicode_RichCompare() ? > Added file: http://bugs.python.org/file12341/cmps5.patch ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 15:58:41 2008 From: report at bugs.python.org (Jon Ribbens) Date: Mon, 15 Dec 2008 14:58:41 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229353121.07.0.325062646201.issue1673409@psf.upfronthosting.co.za> Jon Ribbens added the comment: > A timedelta.toseconds method (or equivalent) makes no sense. > The number of seconds in a day is not fixed (due to leap seconds) and > relying on such a method would introduce subtle bugs. You are misunderstanding what timedelta is. It is a fixed-length period of time. It is stored as a number of (24x3600-second) days, seconds and microseconds. There is no "start date" or "end date", so the concept of leap seconds just does not apply. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 16:31:02 2008 From: report at bugs.python.org (Sebastian Rittau) Date: Mon, 15 Dec 2008 15:31:02 +0000 Subject: [issue2155] optparse.OptionGroup with_statement context handling In-Reply-To: <1203608881.22.0.564217354476.issue2155@psf.upfronthosting.co.za> Message-ID: <1229355062.29.0.454979229492.issue2155@psf.upfronthosting.co.za> Sebastian Rittau added the comment: This API is too "magical" to my liking and doesn't really reflect what context manager's are supposed to do, i.e. handling resources. Also, I don't see much advantage over: group = OptionGroup(parser, "Group name") group.add_option(...) parser.add_option_group(group) Finally, the __exit__ handler adds the option group to the parser in any case, whether there was an exception raised inside the block or not. ---------- nosy: +srittau _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 16:34:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 15:34:40 +0000 Subject: [issue3106] speedup some comparisons In-Reply-To: <49466C92.4060409@egenix.com> Message-ID: <1229355265.12181.6.camel@localhost> Antoine Pitrou added the comment: Le lundi 15 d?cembre 2008 ? 14:41 +0000, Marc-Andre Lemburg a ?crit : > Why have you removed the complete error handling section in > PyUnicode_RichCompare() ? Because the only error that can occur is a TypeError when one of the two arguments is not an unicode object, and that is handled by returning Py_NotImplemented at the end. (there is no implicit bytes -> unicode coercion anymore, and therefore things are much simpler) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:27:34 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 15 Dec 2008 16:27:34 +0000 Subject: [issue4665] Failure to compile trunk on Solaris10/SPARC using C++ compiler In-Reply-To: <18757.30636.523605.327524@montanaro-dyndns-org.local> Message-ID: <1229358454.14.0.976607733862.issue4665@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Closing as "won't fix" for now. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:48:28 2008 From: report at bugs.python.org (Gregg Lind) Date: Mon, 15 Dec 2008 16:48:28 +0000 Subject: [issue4568] Improved optparse "varargs" callback example In-Reply-To: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za> Message-ID: <1229359708.65.0.79488814173.issue4568@psf.upfronthosting.co.za> Gregg Lind added the comment: This patch should also be applied into the py3k branch, probably. Good catch on updating rargs, btw. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:55:40 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 15 Dec 2008 16:55:40 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1229277935.97.0.308591583982.issue4575@psf.upfronthosting.co.za> Message-ID: <18758.35841.822793.582339@montanaro-dyndns-org.local> Skip Montanaro added the comment: Took me awhile to locate a SPARC C compiler on our dwindling set of Solaris/SPARC boxes at work, but I eventually found one and got Subversion trunk to compile. test_cmath and test_math both pass with the force_to_memory2 patch. I don't know if I mentioned it earlier (replying by email), but it also works for me on Mac OS X 10.5.5 (Intel Core2 Duo). Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 18:06:57 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Dec 2008 17:06:57 +0000 Subject: [issue4568] Improved optparse "varargs" callback example In-Reply-To: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za> Message-ID: <1229360817.46.0.938422754426.issue4568@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, it will be merged to py3k automatically; we normally merge smaller changes in batches. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 18:09:13 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 15 Dec 2008 17:09:13 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1229360953.81.0.149523034735.issue4575@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks, Skip. Looks like this problem is 'solved in principle'. Now I have to figure out a non-hackish solution. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 19:48:06 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 15 Dec 2008 18:48:06 +0000 Subject: [issue4501] asyncore's urgent data management and connection closed events are broken when using poll() In-Reply-To: <1228266655.05.0.188613442109.issue4501@psf.upfronthosting.co.za> Message-ID: <1229366886.36.0.457512267504.issue4501@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- versions: +Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 20:15:21 2008 From: report at bugs.python.org (Jeremy Hylton) Date: Mon, 15 Dec 2008 19:15:21 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229368521.94.0.62183996498.issue4631@psf.upfronthosting.co.za> Jeremy Hylton added the comment: I have a patch here that seems to work for the specific url and that passes all the tests. Can anyone check whether it works for a larger set of cases? I'm a little concerned because I don't understand the new io library in much detail. There's an override for _checkClosed() in the HTTPResponse that seems a little dodgy. I'll try to get someone to review that specifically. Added file: http://bugs.python.org/file12361/urllib-chunked.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 20:24:08 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 15 Dec 2008 19:24:08 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229369048.3.0.79984106648.issue1673409@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 20:27:58 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 15 Dec 2008 19:27:58 +0000 Subject: [issue3106] speedup some comparisons In-Reply-To: <1229355265.12181.6.camel@localhost> Message-ID: <4946AFBA.2000501@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-15 16:34, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > Le lundi 15 d?cembre 2008 ? 14:41 +0000, Marc-Andre Lemburg a ?crit : >> Why have you removed the complete error handling section in >> PyUnicode_RichCompare() ? > > Because the only error that can occur is a TypeError when one of the two > arguments is not an unicode object, and that is handled by returning > Py_NotImplemented at the end. > (there is no implicit bytes -> unicode coercion anymore, and therefore > things are much simpler) Ah, sorry, just saw that this is just for Py3. The fast-path would probably also make sense for Py2 (keeping the error handling, of course). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:27:14 2008 From: report at bugs.python.org (Jim_C) Date: Mon, 15 Dec 2008 21:27:14 +0000 Subject: [issue4671] pydoc executes the code to be documented In-Reply-To: <1229376434.19.0.800052631244.issue4671@psf.upfronthosting.co.za> Message-ID: <1229376434.19.0.800052631244.issue4671@psf.upfronthosting.co.za> New submission from Jim_C : Running pydoc [ pydoc ] on a python module using Tkinter displayed the window defined in the module - not what I was expecting.. Running pydoc on from os import remove sFile='tmp.tmp' remove(sFile) will remove the file tmp.tmp, if it exists. If this behaviour is intentional ( as it appears to be, see imp.load_module ) & presumably integral to the operation of pydoc, then it might be worth providing a warning on the web page ( http://docs.python.org/library/pydoc.html ) ?? Running a code with default arguments in an arbitrary directory could potentially produce unwanted side effects, at the very least.. Regards , Jim_C ---------- messages: 77881 nosy: Jim_C severity: normal status: open title: pydoc executes the code to be documented type: behavior versions: Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:42:20 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 15 Dec 2008 21:42:20 +0000 Subject: [issue3954] _hotshot: invalid error control in logreader() In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za> Message-ID: <1229377340.44.0.745914245043.issue3954@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- assignee: -> amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:17:05 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 15 Dec 2008 22:17:05 +0000 Subject: [issue3954] _hotshot: invalid error control in logreader() In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za> Message-ID: <1229379425.36.0.971957856126.issue3954@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Fixed in r67797 (trunk) and r67801 (2.6) hotshot was removed from py3k. ---------- resolution: accepted -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:22:32 2008 From: report at bugs.python.org (Andy Buckley) Date: Mon, 15 Dec 2008 22:22:32 +0000 Subject: [issue4672] Distutils SWIG support blocks use of SWIG -outdir option In-Reply-To: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za> Message-ID: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za> New submission from Andy Buckley : When using distutils to build an extension module using SWIG, it makes most sense to use the built-in SWIG support. However, the distutils seem to "vet" the options passed via the Extension.swig_opts attr/arg: [...] ext_modules=[Extension('_hepmc', ['@top_srcdir@/hepmc.i'], swig_opts=['-c++', '-I at HEPMCINCPATH@', '-outdir .'], include_dirs=['@HEPMCINCPATH@'], library_dirs=['@HEPMCLIBPATH@'], libraries=['HepMC'])], [...] results in this error: building '_hepmc' extension swigging ./hepmc.i to ./hepmc_wrap.cpp swig -python -c++ -I/home/andy/heplocal/include -outdir . -o ./hepmc_wrap.cpp ./hepmc.i swig error : Unrecognized option -outdir . Use 'swig -help' for available options. error: command 'swig' failed with exit status 1 but calling the same swig command works fine. It's the same copy of swig, but it seems to be distutils rather than swig that is throwing the error. This is particularly relevant since I need to use -outdir to meet the autotools "distcheck" requirement of successfully building from a build-dir separate from the source dir: code generation tools like SWIG blur such a distinction and so need to support output location flags like -outdir. I see this was also noticed some time ago: http://osdir.com/ml/python.distutils.devel/2006-06/msg00009.html but no useful reply was ever forthcoming ;( Maybe this time will be luckier! ---------- components: Distutils messages: 77883 nosy: andybuckley severity: normal status: open title: Distutils SWIG support blocks use of SWIG -outdir option type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:28:00 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 22:28:00 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229380080.59.0.620029313372.issue4561@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've written a small file IO benchmark, available here: http://svn.python.org/view/sandbox/trunk/iobench/ It runs under both 2.6 and 3.x, so that we can compare speeds of respective implementations. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:28:54 2008 From: report at bugs.python.org (Andy Buckley) Date: Mon, 15 Dec 2008 22:28:54 +0000 Subject: [issue4673] Distutils should provide an uninstall command In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za> Message-ID: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za> New submission from Andy Buckley : It would make package maintenance easier, as well as integration with other build systems e.g. autotools (necessary for projects where not everything is Python), if the distutils supported an uninstallation command, e.g. python setup.py uninstall This would presumably require monitoring of which files were installed where, and it's of course possible to do undesirable things, but exactly the same counter-arguments exist for autotools, and there the uninstall target is an important and useful feature for developers, once you know how to behave in a way to make it safe. ---------- components: Distutils messages: 77885 nosy: andybuckley severity: normal status: open title: Distutils should provide an uninstall command type: feature request versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:29:29 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 15 Dec 2008 22:29:29 +0000 Subject: [issue3632] use string_print() in gdb In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za> Message-ID: <1229380169.71.0.0609878520144.issue3632@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Committed in r67802. ---------- resolution: accepted -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:32:55 2008 From: report at bugs.python.org (Andy Buckley) Date: Mon, 15 Dec 2008 22:32:55 +0000 Subject: [issue1479255] Fix building with SWIG's -c++ option set in setup.py Message-ID: <1229380375.96.0.00807824081638.issue1479255@psf.upfronthosting.co.za> Andy Buckley added the comment: This works in my current version of distutils (Python 2.5.2, from Ubuntu Intrepid). Maybe it was fixed and no-one noticed that this bug was relevant ;) ---------- nosy: +andybuckley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:34:22 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 22:34:22 +0000 Subject: [issue4666] test_bad_address in test_urllib2_localnet often fails In-Reply-To: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za> Message-ID: <1229380462.34.0.93639930511.issue4666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: On the buildbots, the errors have now disappeared after the "fix". I'm closing this, please reopen it if you still witness it. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 00:00:13 2008 From: report at bugs.python.org (Daniel Diniz) Date: Mon, 15 Dec 2008 23:00:13 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229382013.2.0.313648302875.issue4631@psf.upfronthosting.co.za> Daniel Diniz added the comment: I think your patch is good, but there may be another bug around: I wrote a script to check results of 3.x against 2.x, but many pages (http://groups.google.com/, http://en.wikipedia.org/) give 403: Forbidden for 3.x... but work with 2.x! If you think of this as a bug in 3.x, it could retry the request identifying as 2.x on 403. Other than that, your patch gives me identical results to 2.5/2.6 for 128 sites I tested (only a read(100) for each). Interestingly, my patched version gives a file closer to the buggy version in size, at 12700 bytes versus 12707. Your version agrees with 2.x and simple maths (128 x 100) in giving a 12799 bytes result. I have no idea why. HTH, Daniel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 00:04:19 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 23:04:19 +0000 Subject: [issue4663] Increase TextIOWrapper._CHUNK_SIZE In-Reply-To: <1229278711.0.0.240635346547.issue4663@psf.upfronthosting.co.za> Message-ID: <1229382259.88.0.558915623656.issue4663@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed in r67803, r67804. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 00:25:20 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Mon, 15 Dec 2008 23:25:20 +0000 Subject: [issue4216] subprocess.Popen hangs at communicate() when child exits In-Reply-To: <1225151867.64.0.844146967045.issue4216@psf.upfronthosting.co.za> Message-ID: <1229383520.51.0.921073409236.issue4216@psf.upfronthosting.co.za> Gabriel Genellina added the comment: I think communicate() works as documented now: reads stdout/stderr until EOF, *and* waits for subprocess to terminate. You're asking for a different method, or perhaps an optional parameter "return_when_died" to communicate, so it returns as soon as the child process terminates (I don't like the parameter name...) I think this is more a feature request than a crash, targeted to 2.7/3.1 - 2.4 only gets security fixes anyway. ---------- nosy: +gagenellina type: crash -> feature request versions: +Python 2.7, Python 3.1 -Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 00:50:33 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Dec 2008 23:50:33 +0000 Subject: [issue4671] pydoc executes the code to be documented In-Reply-To: <1229376434.19.0.800052631244.issue4671@psf.upfronthosting.co.za> Message-ID: <1229385033.45.0.378588186257.issue4671@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That's why you shouldn't put code with side effects at the root of a module, but inside a "if __name__ == '__main__'" guard. Anyway, it may be worth documenting it! ---------- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl, pitrou versions: +Python 2.6 -Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 01:20:36 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Tue, 16 Dec 2008 00:20:36 +0000 Subject: [issue4640] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za> Message-ID: <1229386836.5.0.040759707768.issue4640@psf.upfronthosting.co.za> Gabriel Genellina added the comment: could you provide a test case / code fragment showing the bug? ---------- components: +Library (Lib) -Extension Modules nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 01:28:58 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Tue, 16 Dec 2008 00:28:58 +0000 Subject: [issue4643] cgitb.html fails if getattr call raises exception In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> Message-ID: <1229387338.14.0.406389781859.issue4643@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 02:23:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 01:23:12 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1229380080.59.0.620029313372.issue4561@psf.upfronthosting.co.za> Message-ID: <1229390584.14851.4.camel@localhost> Antoine Pitrou added the comment: Without Christian's patch: [400KB.txt] read one byte/char at a time... 0.2685 MB/s (100% CPU) [400KB.txt] read 20 bytes/chars at a time... 4.536 MB/s (98% CPU) [400KB.txt] read one line at a time... 3.805 MB/s (99% CPU) [400KB.txt] read 4096 bytes/chars at a time... 29.23 MB/s (100% CPU) [ 20KB.txt] read whole contents at once... 52.42 MB/s (99% CPU) [400KB.txt] read whole contents at once... 45.83 MB/s (100% CPU) [ 10MB.txt] read whole contents at once... 48.78 MB/s (99% CPU) With the patch: [400KB.txt] read one byte/char at a time... 0.2761 MB/s (100% CPU) [400KB.txt] read 20 bytes/chars at a time... 4.656 MB/s (99% CPU) [400KB.txt] read one line at a time... 3.956 MB/s (98% CPU) [400KB.txt] read 4096 bytes/chars at a time... 33.85 MB/s (100% CPU) [ 20KB.txt] read whole contents at once... 66.17 MB/s (99% CPU) [400KB.txt] read whole contents at once... 56.65 MB/s (99% CPU) [ 10MB.txt] read whole contents at once... 63.69 MB/s (99% CPU) Python 2.6's builtin file object: [400KB.txt] read one byte/char at a time... 1.347 MB/s (97% CPU) [400KB.txt] read 20 bytes/chars at a time... 26.65 MB/s (99% CPU) [400KB.txt] read one line at a time... 184.4 MB/s (100% CPU) [400KB.txt] read 4096 bytes/chars at a time... 1163 MB/s (99% CPU) [ 20KB.txt] read whole contents at once... 1072 MB/s (100% CPU) [400KB.txt] read whole contents at once... 889.1 MB/s (100% CPU) [ 10MB.txt] read whole contents at once... 600 MB/s (100% CPU) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 06:12:07 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 05:12:07 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229404327.91.0.419027783722.issue4561@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm getting caught-up with the IO changes in 3.0 and am a bit confused. The PEP says, "programmers who don't want to muck about in the new I/O world can expect that the open() factory method will produce an object backwards-compatible with old-style file objects." So, I would have expected that the old implementation could have remained in-place and the resultant object registered as matching the appropriate IO ABC. If that had been done, the performance would be unchanged. Does anyone know why the entire old implementation had to be thrown-out in cases where the API was unchanged? Is there anything about New IO that is fundamentally different so that the old implementation had to be tossed in all cases? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:55:20 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 16 Dec 2008 08:55:20 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229417720.1.0.0844145333747.issue4561@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The previous implementation only returns bytes and does not translate newlines. For this particular case, indeed, the plain old FILE* based object is faster. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 12:08:17 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 16 Dec 2008 11:08:17 +0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1229425697.99.0.276806671545.issue1673409@psf.upfronthosting.co.za> Changes by Marc-Andre Lemburg : ---------- nosy: -lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 13:41:43 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 12:41:43 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229431303.3.0.869291081934.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In the whatsnew docs, add two lines showing the binary representation of 37. That will provide clarification as to why the answer is six: >>> n = 37 + >>> bin(37) + '0b100101' >>> n.bit_length() 6 Also, the main entry in the docs should be built-out just a bit. I like that the current entry provides a precise mathematical spec that is easily validated, but it should also mention the more intuitive notion of the "number of bits in a number's binary representation excluding leading zeros (for example the decimal number 37, which is 0b100101 in binary, has six binary digits)." Possibly, the BitLengthTables can be dropped in favor of the old shift-one, add-one code (to be inserted right after the shift-eight, add-eight code). The two tables consume a lot of memory and the relevant entry is not likely to be in cache when needed (cache misses are very slow). It is simpler and possibly faster to skip the table lookup unless the table is made much smaller. Plus, it makes the code a bit more maintainable and self-evidently correct (not requiring as extensive test coverage to validate the whole table). My own crack at optimization looks like this: static const char BitLengthTable[32] = {0, 1, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5}; while (n >= 32) { r += 5; n >>= 5; } r += (long)(BitLengthTable[n]); If you don't adopt mine, at least consider making a table of chars instead of longs (this will give a 4:1 or 8:1 table compression, reducing the memory footprint and increasing the likelihood of a cache hit). I would feel better about the test code if it also directly validated the definitions in docs and thoroughly exercised the tables: for x in range(-65000, 65000): k = x.numbits if x > 0: assert 2 ** (k-1) <= x < 2**k assert k == 1 + math.floor(math.log(x) / math.log(2)) elif x == 0: assert k == 0 else: assert k == (-x).numbits() Other than that, I'm basically happy with the patch. ---------- assignee: rhettinger -> marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 13:47:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 12:47:13 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229431633.92.0.587074592179.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Oops, forgot one part of the doc definition in the proposed additional tests: for x in range(-65000, 65000): k = x.numbits() assert k == len(bin(x).lstrip('-0b')) if x > 0: assert 2 ** (k-1) <= x < 2**k assert k == 1 + math.floor(math.log(x) / math.log(2)) elif x == 0: assert k == 0 else: assert k == (-x).numbits() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:09:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 13:09:39 +0000 Subject: [issue4674] test_normalization failures on some buildbot In-Reply-To: <1229432979.42.0.68448334013.issue4674@psf.upfronthosting.co.za> Message-ID: <1229432979.42.0.68448334013.issue4674@psf.upfronthosting.co.za> New submission from Antoine Pitrou : test_normalization intermittently fails on some buildbots with the following message: Traceback (most recent call last): File "./Lib/test/regrtest.py", line 596, in runtest_inner the_package = __import__(abstest, globals(), locals(), []) File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/test/test_normalization.py", line 13, in l = f.readline() File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/io.py", line 1810, in readline while self._read_chunk(): File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/io.py", line 1559, in _read_chunk self._set_decoded_chars(self._decoder.decode(input_chunk, eof)) File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/io.py", line 1292, in decode output = self.decoder.decode(input, final=final) File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 1129: ordinal not in range(128) ---------- components: Tests messages: 77899 nosy: pitrou priority: high severity: normal status: open title: test_normalization failures on some buildbot type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:19:59 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 13:19:59 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229433599.24.0.624688513551.issue4561@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I seem to recall one of the design principles of the new IO stack was to avoid relying on the C stdlib's buffered API, which has too many platform-dependant behaviours. In any case, binary reading has acceptable performance in py3k (although 3x-4x slower than in 2.x), it's text I/O which is truely horrendous. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:27:00 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 13:27:00 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229434020.01.0.593219777625.issue4561@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't agree that that was a worthy design goal. Tons of code (incl the old CPython successfully used the stdlib functions). IMO, a 3x or 4x falloff for binary reads/writes is a significant disincentive for adopting Py3.0. For binary reads/writes, I would like to see the open() factory function return the old, fast object instead to trying to slowly simulate it without adding any benefits noticeable to an end-user. IMO, it's a case of practicality beating purity. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:28:20 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 16 Dec 2008 13:28:20 +0000 Subject: [issue4501] asyncore's urgent data management and connection closed events are broken when using poll() In-Reply-To: <1228266655.05.0.188613442109.issue4501@psf.upfronthosting.co.za> Message-ID: <1229434100.2.0.261329850583.issue4501@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: IMHO it would be good if this could go in the latest 2.4 and 2.5 upcoming releases while we still have the chance. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:47:54 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 16 Dec 2008 13:47:54 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229435274.27.0.485202136997.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: I agree with Raymond. For binary reads, I'll go farther and say that even a 10% slowdown in performance would be surprising if not unacceptable to some people. I know that as hard as it might be for everyone to believe, there are a lot of people who crank lots of non- Unicode data with Python. In fact, Python 2.X is pretty good at it. It's fine that text mode now uses Unicode, but if I don't want that, I would certainly expect the binary file modes to run at virtually the same speed as Python 2 (e.g., okay, they work with bytes instead of strings, but is the bytes type really all that different from the old Python 2 str type?). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:50:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 13:50:36 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1229434020.01.0.593219777625.issue4561@psf.upfronthosting.co.za> Message-ID: <1229435429.10551.4.camel@localhost> Antoine Pitrou added the comment: > I don't agree that that was a worthy design goal. I don't necessarily agree either, but it's probably too late now. The py3k buffered IO object has additional methods (e.g. peek(), read1()) which can be used by upper layers (text IO) and so can't be replaced with the old 2.x file object. In any case, Amaury has started rewriting the IO lib in C (*) and getting good binary IO performance shouldn't be too difficult. (*) http://svn.python.org/view/sandbox/trunk/io-c/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:56:08 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2008 13:56:08 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229435768.95.0.333435931775.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: x.numbits() is: math.ceil(math.log(abs(x)) / math.log(2)) if x != 0 0 otherwise and not 1 + math.floor(math.log(x) / math.log(2)) (16).numbits() is 4, not 5. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:56:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 13:56:15 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1229435274.27.0.485202136997.issue4561@psf.upfronthosting.co.za> Message-ID: <1229435769.10551.10.camel@localhost> Antoine Pitrou added the comment: > I know that as hard as it might be for > everyone to believe, there are a lot of people who crank lots of non- > Unicode data with Python. But "cranking data" implies you'll do something useful with it, and therefore spend CPU time doing those useful things (likely much more CPU time than you spent read()ing the data in the first place). In any case, you can try to open your file in unbuffered mode: open("foobar", "rb", buffering=0) it will bypass the Python buffering layer and will go directly to the raw C unbuffered object. > (e.g., okay, they work with bytes instead of > strings, but is the bytes type really all that different from the old > Python 2 str type?) No. It's a bit more limited, doesn't support autoconversion to/from unicode, but that's all. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:57:22 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 13:57:22 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1229435768.95.0.333435931775.issue3439@psf.upfronthosting.co.za> Message-ID: <1229435836.10551.11.camel@localhost> Antoine Pitrou added the comment: Le mardi 16 d?cembre 2008 ? 13:56 +0000, STINNER Victor a ?crit : > (16).numbits() is 4, not 5. Well, I do hope (16).numbits() returns 5... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 15:00:02 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2008 14:00:02 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229436002.67.0.899881356421.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: Ooops, you're right! (15).numbits() -> 4 and (16).numbits() -> 5. I'm tired. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 15:04:06 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 14:04:06 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229436246.25.0.366274018495.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: One other thought on the docs. I would like to continue the style of supplying pure python equivalents to help precisely explain what a function does (see the itertools docs for an example, also a few builtins are explained that way and namedtuples too): + Equivalent to:: + + def numbits(x): + 'Number of binary bits necessary to represent the integer n' + return len(bin(x).lstrip('-0b')) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 15:07:39 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 16 Dec 2008 14:07:39 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229436459.56.0.451809761495.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: Good luck with that. Most people who get bright ideas such as "gee, maybe I'll write my own version of X" where "X" is some part of the standard C library pertaining to I/O, end up fighting a losing battle. Of course, I'd love to be proven wrong, but I don't think I will in this case. As for cranking data, that does not necessarily imply heavy-duty CPU processing. Someone might be reading large datafiles simply to perform some kind of data extraction, filtering, minor translation, or other operation that is easily carried out in Python, but where the programs are still I/O bound. For example, the kinds of processing one might otherwise do using awk, sed, perl, etc. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 15:11:06 2008 From: report at bugs.python.org (Fredrik Johansson) Date: Tue, 16 Dec 2008 14:11:06 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229436666.56.0.0404393463889.issue3439@psf.upfronthosting.co.za> Fredrik Johansson added the comment: When did the name change back to numbits? Anyway, I think this reference implementation is better: def numbits(x): x = abs(x) n = 0 while x: n += 1 x //= 2 return n (//= 2 could be changed to >>= 1) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 15:20:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Dec 2008 14:20:55 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229437255.8.0.100062620413.issue4561@psf.upfronthosting.co.za> Christian Heimes added the comment: David: Amaury's work is going to be a part of the standard library as soon as his work is done. I'm confident that we can reach the old speed of the 2.x file type by carefully moving code to C modules. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 15:53:57 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2008 14:53:57 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229439237.61.0.501652826669.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: Please don't promote this ugly code "len(bin(x).lstrip('-0b'))". It's not the best way to compute the number of bits... I prefer fredrikj's proposition (with // 2, few people understand >> 1). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 16:24:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 15:24:56 +0000 Subject: [issue4674] test_normalization failures on some buildbot In-Reply-To: <1229432979.42.0.68448334013.issue4674@psf.upfronthosting.co.za> Message-ID: <1229441096.19.0.723968845208.issue4674@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Should be fixed (r67814, r67815). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 16:58:24 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 16 Dec 2008 15:58:24 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229443104.25.0.331775326341.issue4561@psf.upfronthosting.co.za> David M. Beazley added the comment: I wish I shared your optimism about this, but I don't. Here's a short explanation why. The problem of I/O and the associated interface between hardware, the operating system kernel, and user applications is one of the most fundamental and carefully studied problems in all of computer systems. The C library and its associated I/O functionality provide the user- space implementation of this interface. However, if you peel the covers off of the C library, you're going to find a lot of really hairy stuff in there. Examples might include: 1. Low-level optimization related to the system hardware (processor architecture, caching, I/O bus, etc.). 2. Hand-written finely tuned assembly code. 3. Low-level platform-specific system calls such as ioctl(). 4. System calls related to shared memory regions, kernel buffers, etc. (i.e., optimizations that try to eliminate buffer copies). 5. Undocumented vendor-specific "proprietary" system calls (i.e., unknown "magic"). So, you'll have to forgive me for being skeptical, but I just don't think any programmer is going to sit down and bang out a new implementation of buffered I/O that is going to match the performance of what's provided by the C library. Again, I would love to be proven wrong. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 18:01:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 17:01:58 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229446918.54.0.393473199965.issue4653@psf.upfronthosting.co.za> Mark Dickinson added the comment: It looks to me as though all these are valid, and the patch should be applied to py3k and the 3.0 maintenance branch. Minor nit: the "sizeof(theInfo)" line exceeds 79 characters, in violation of PEP 7. Is there any core developer who's in a position to test this patch on Windows? ---------- nosy: +marketdickinson stage: -> commit review versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:23:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 18:23:09 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1229443104.25.0.331775326341.issue4561@psf.upfronthosting.co.za> Message-ID: <1229451777.7296.9.camel@localhost> Antoine Pitrou added the comment: [...] Although I agree all this is important, I'd challenge the assumption it has its place in the buffered IO library rather than in lower-level layers (i.e. kernel & userspace unbuffered IO). In any case, it will be difficult to undo the current design decisions (however misguided they may or may not be) of the py3k IO library and we'll have to make the best out of them! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:33:20 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 16 Dec 2008 18:33:20 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229452400.39.0.130886056827.issue3439@psf.upfronthosting.co.za> Skip Montanaro added the comment: Regarding the last few posts: * Raymond's implementation, while ugly, provides a completely orthogonal way to test compute numbits, useful in unit tests if nothing else. * Using x >> 1 in a reference implementation is perfectly reasonable. If the person using the reference implementation to produce a real C-based implementation doesn't understand the equivalence of x // 2 and x >> 1, heaven help us. Skip ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:27:12 2008 From: report at bugs.python.org (Mihai Ibanescu) Date: Tue, 16 Dec 2008 19:27:12 +0000 Subject: [issue4675] urllib's splitpasswd does not accept newline chars in passwords In-Reply-To: <1229455632.0.0.358250268025.issue4675@psf.upfronthosting.co.za> Message-ID: <1229455632.0.0.358250268025.issue4675@psf.upfronthosting.co.za> New submission from Mihai Ibanescu : According to http://www.ietf.org/rfc/rfc2617.txt section 2, in basic HTTP authentication the password can be any character (including newline). urllib does the following: _passwdprog = re.compile('^([^:]*):(.*)$') That should be changed to: _passwdprog = re.compile('^([^:]*):(.*)$', re.S) otherwise newlines will not be caught by the second part of the regex, and bad things are produced. For a password with regular chars in it: > python -c "import urllib; print urllib.splitpasswd('user:ab')" ('user', 'ab') For a password with a newline: > python -c "import urllib; print urllib.splitpasswd('user:a\nb')" ('user:a\nb', None) The expected result should have been ('user', 'a\nb') ---------- components: Library (Lib) messages: 77919 nosy: mibanescu severity: normal status: open title: urllib's splitpasswd does not accept newline chars in passwords type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:41:53 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 19:41:53 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229456513.77.0.266207058851.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for all the comments. Here's an updated patch, with quite a few changes: code: - drop lookup tables in favour of "while(x) {x >>= 1; count += 1;}" - add example to docstring, and use PyDoc_STRVAR macro for docstrings docs: - add "bin(37)" to whatsnew example - move main documentation out of the bit operations table into its own subsection, so that it can be indexed properly. - expand main documentation with examples, informal definition, equivalent Python code - I dropped the 1 + math.floor(...) definition from the docs, judging that 1 informal, 1 formal and 1 Python definition should be enough. tests: - as proposed by Raymond, directly check equivalence with formal definition, equivalent Python code, and two other possible definitions. (FWIW I prefer 'x>>1' over 'x//2' in the Python code, because it's more immediately related to the intended sense: the operation should be thought of as a bit shift rather than a division.) Added file: http://bugs.python.org/file12362/bit_length8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:42:21 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 19:42:21 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229456541.98.0.435204617139.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- components: +Interpreter Core -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:43:43 2008 From: report at bugs.python.org (Somelauw) Date: Tue, 16 Dec 2008 19:43:43 +0000 Subject: [issue4676] python3 closes + home keys In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za> Message-ID: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za> New submission from Somelauw : I'm using python 3.0 final which was released on December the 3th. I also have python 2.5 installed. 2 bugs in python3 IDLE which might be related (but don't have to) 1. The Python3 IDLE sometimes suddenly closes. It always happens when I'm using it for a while, then press the shift + home or end key and then it just disappears and my unsaved work is lost. It really completely exits without an error and I also don't see it on the background. I'm unable to reproduce the error. But it usually happens when I have hold down shift and press the home key. 2. When I have some code then scroll down the code, then hold down shift and press up a few times, then press home the selected code completely switches. Instead some code above the cursor suddenly gets selected. The reason I think both are related is because both involve shift + home key. Both of the bugs have never happened in the IDLE 1.2.1 which was part of python 2.5.2 I think ---------- components: IDLE messages: 77921 nosy: Somelauw severity: normal status: open title: python3 closes + home keys versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:44:04 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 19:44:04 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229456644.39.0.0274303060729.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Of course, the name should have been bit_length() instead of numbits(). For the code equivalent, I'm aiming for something less process oriented and more focused on what it does. bit_length IS the number of bits in a binary representation without the sign or leading zeroes -- that definition IS a correct mental picture and does not require special cases for zero or for negatives. The purpose of the code equivalent is not efficiency or beauty; it to help communicate was a function does. If you want it to be more beautiful, it can be broken into multiple lines. I don't think you gain ANY explanatory power with code that says: bit_length is the number of right-shifts (or floor divisions by two) of the absolute value of a number until that number becomes zero. Tell that description to a high school student and prepare for a blank stare. FWIW, I think having a mental picture that was too process oriented was behind last night's mistake of thinking the (16).bit_length() was 5 instead of 4. I theorize that error wouldn't have occurred if the mental picture was of len('10000') instead of power-of-two mental model where people (including some of the commenter here) tend to get the edge cases wrong. It would be better to have no code equivalent at all than to present the repeated //2 method as a definition. That is a process, but not a useful mental picture to help explain what bit_length is all about. Think about it, bit_length() is about the length in bits of a binary representation -- any code provided needs to translate directly to that definition. def bit_length(x): '''Length of a binary representation without the sign or leading zeroes: >>> (-37).numbits() 6 ''' s = bin(x) # binary representation: bin(-37) --> '-0b100101' s = s.lstrip('-0b') # remove leading zeros and sign return len(s) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:51:54 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 19:51:54 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229457114.6.0.489997759426.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Okay; I don't have strong feelings about the form the Python code takes; I'll let you guys argue it out and then fix things accordingly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:16:59 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 20:16:59 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229458619.05.0.821262676388.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: IMO, the choices are something like my version or none at all. The repeated floor division by two of abs(x) has ZERO explanatory power and may even detract from a beginner's ability to understand what the method does. Show that code to most finance people and they will avoid the method entirely. Anyone who disagrees needs to show both code fragments to some junior programmers and see which best leads to understanding the method and being able to correctly predict the edge cases bordering powers of two, the zero case, and how negatives are handled. No fair trying this experiment on assembly language programmers ;-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:20:29 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 20:20:29 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1229458619.05.0.821262676388.issue3439@psf.upfronthosting.co.za> Message-ID: <1229458822.7296.22.camel@localhost> Antoine Pitrou added the comment: > Show that code to most finance people and they will avoid the > method entirely. Why would finance people be interested in bit_length()? I think this discussion begins to feel like bikeshedding. Documentation can always be improved afterwards. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:30:03 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 20:30:03 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459403.27.0.70983542961.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Antoine, it's not bike-shedding at all. Communicative docs are important to users other than assembly language programmers. BTW, I am a finance person (a CPA). Yes, you're correct, I can fix-up the docs after the patch is posted. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:33:57 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 20:33:57 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1229459637.11.0.987528547386.issue4580@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Any news? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:34:31 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 20:34:31 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459671.6.0.829736687567.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Updated patch. Added file: http://bugs.python.org/file12363/bit_length9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:34:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 20:34:37 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459677.77.0.270831185928.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12348/bit_length7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:34:43 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 20:34:43 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459683.6.0.224558369394.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12349/bit_length7_opt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:34:47 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 20:34:47 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459687.54.0.454888490081.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12362/bit_length8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:37:05 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 16 Dec 2008 20:37:05 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459825.78.0.595626578469.issue3439@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- nosy: -loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:39:17 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 20:39:17 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459957.95.0.401124984726.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Bah. Fix test_int so that it actually works. Added file: http://bugs.python.org/file12364/bit_length10.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:39:25 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 20:39:25 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229459965.89.0.428115242504.issue3439@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file12363/bit_length9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:45:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 20:45:26 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229460326.87.0.459011716913.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: ...and use proper unittest methods instead of asserts... Added file: http://bugs.python.org/file12365/bit_length11.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:45:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 20:45:42 +0000 Subject: [issue4486] Exception traceback is incorrect for strange exception handling In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za> Message-ID: <1229460342.41.0.691399860672.issue4486@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. Should it go in? ---------- keywords: +needs review, patch stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file12366/issue4486.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 22:00:30 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 21:00:30 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229461230.96.0.8200809756.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Looks good. Marking as accepted. Before applying, consider adding back the part of the docs with the '1 + floor(...' definition. I think it provides a useful alternative way to look at what the method does. Also, it gives a useful mathematical expression that can be used in reasoning about invariants. More importantly, we should provide it because it is so easy to make a mistake when rolling your own version of the formula (i.e. using ceil instead of floor or having an off by one error). ---------- resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 22:03:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 21:03:35 +0000 Subject: [issue4426] UTF7 decoding is far too strict In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za> Message-ID: <1229461415.65.0.211508351028.issue4426@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not in a position to comment on the encoding algorithm itself but I have a couple of comments: * I get the following compilation warning: Objects/unicodeobject.c: In function ?PyUnicode_DecodeUTF7Stateful?: Objects/unicodeobject.c:1531: attention : ?shiftOutStart? may be used uninitialized in this function * shouldn't there be an additional test for the '/' behaviour (unless it is already there and I have overlooked it)? * your patch fails on another test: Traceback (most recent call last): File "Lib/test/test_unicode.py", line 538, in test_codecs_utf7 self.assertRaises(UnicodeDecodeError, '+\xc1'.decode, 'utf-7') AssertionError: UnicodeDecodeError not raised ---------- keywords: +needs review, patch priority: -> critical stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 22:27:23 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 21:27:23 +0000 Subject: [issue4583] segfault when mutating memoryview to array.array when array is resized In-Reply-To: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za> Message-ID: <1229462843.85.0.636176275542.issue4583@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nothing new in this patch except that it fixes the bogus indentation of the previous patch. Added file: http://bugs.python.org/file12367/arraybuf2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 22:32:28 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 21:32:28 +0000 Subject: [issue4583] segfault when mutating memoryview to array.array when array is resized In-Reply-To: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za> Message-ID: <1229463148.13.0.493745234434.issue4583@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +teoliphant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 22:38:30 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 16 Dec 2008 21:38:30 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229463510.55.0.291488803217.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Before applying, consider adding back the part of the docs with the '1 + > floor(...' definition. My only (minor) objection to this definition is that a straight Python translation of it doesn't work, thanks to roundoff error and the limited precision of floating-point: >>> from math import floor, log >>> n = 2**101 >>> n.bit_length() 102 >>> 1 + floor(log(n)/log(2)) 101.0 >>> n = 2**80-1 >>> n.bit_length() 80 >>> 1 + floor(log(n)/log(2)) 81.0 But as you say, it provides another perspective; I'm fine with putting it back in. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 22:41:33 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 21:41:33 +0000 Subject: [issue477863] New gc work Message-ID: <1229463693.21.0.870576194373.issue477863@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Although this dates back to 2001, I think this might still be useful. ---------- components: +Interpreter Core -None nosy: +pitrou versions: +Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 22:45:11 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 21:45:11 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229463911.11.0.393033953533.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Also, consider writing it in the two argument form: 1 + floor(log(n, 2)) and using the word "approximately" or somesuch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 23:19:20 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 22:19:20 +0000 Subject: [issue4677] a list comprehensions tests for pybench In-Reply-To: <1229465960.59.0.848969060815.issue4677@psf.upfronthosting.co.za> Message-ID: <1229465960.59.0.848969060815.issue4677@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This patch adds some measurements of list comprehensions performance to the standard pybench suite. Marc-Andr?, is it ok for you? ---------- components: Demos and Tools files: pybench-listcomps.patch keywords: patch messages: 77938 nosy: lemburg, pitrou priority: normal severity: normal stage: patch review status: open title: a list comprehensions tests for pybench type: performance versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file12368/pybench-listcomps.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 23:27:55 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 22:27:55 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229466475.75.0.144324855782.issue2183@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a new patch against trunk and fixing the documentation for LIST_APPEND. ---------- nosy: +pitrou stage: -> patch review versions: +Python 2.7, Python 3.1 -Python 2.6 Added file: http://bugs.python.org/file12369/list-comp-opt3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:25:25 2008 From: report at bugs.python.org (Eric Eisner) Date: Tue, 16 Dec 2008 23:25:25 +0000 Subject: [issue4678] Unicode: multiple chars for high code points In-Reply-To: <1229469924.95.0.71145202333.issue4678@psf.upfronthosting.co.za> Message-ID: <1229469924.95.0.71145202333.issue4678@psf.upfronthosting.co.za> New submission from Eric Eisner : I discovered this when trying to splice a string containing unicode codepoints higher than U+FFFF all examples on 32-bit Ubuntu Linux python 2.5.2 (for comparison): sys.maxunicode # 1114111 len(unichr(66674)) # 1 len(u'\U00010472') # 1 len(u'??') # 2 unichr(66674)[0] # u'\U00010472' python 3.0: (same behavior on ubuntu's rc1 package and my build(r67781) from svn) sys.maxunicode # 65535 len(chr(66674)) # 2 len('\U00010472') # 2 len('??') # 2 chr(66674)[0] # '\ud801' I expect the nth element of a string to be the nth codepoint, regardless of unicode settings. I don't know why the maxunicode is configured differently (both compiled by ubuntu), but is this the expected behavior? If this is actually the expected behavior, how can I configure a build of python to use the larger maxunicode value? ---------- components: Unicode messages: 77940 nosy: ede severity: normal status: open title: Unicode: multiple chars for high code points versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:41:47 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 16 Dec 2008 23:41:47 +0000 Subject: [issue4678] Unicode: multiple chars for high code points In-Reply-To: <1229469924.95.0.71145202333.issue4678@psf.upfronthosting.co.za> Message-ID: <49483CB8.6090100@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-17 00:25, Eric Eisner wrote: > New submission from Eric Eisner : > > I discovered this when trying to splice a string containing unicode > codepoints higher than U+FFFF > > > all examples on 32-bit Ubuntu Linux > > python 2.5.2 (for comparison): > sys.maxunicode # 1114111 > len(unichr(66674)) # 1 > len(u'\U00010472') # 1 > len(u'??') # 2 > unichr(66674)[0] # u'\U00010472' > > > python 3.0: (same behavior on ubuntu's rc1 package and my build(r67781) > from svn) > sys.maxunicode # 65535 > len(chr(66674)) # 2 > len('\U00010472') # 2 > len('??') # 2 > chr(66674)[0] # '\ud801' > > I expect the nth element of a string to be the nth codepoint, regardless > of unicode settings. I don't know why the maxunicode is configured > differently (both compiled by ubuntu), but is this the expected behavior? > > If this is actually the expected behavior, how can I configure a build > of python to use the larger maxunicode value? You are seeing the different behavior because you've probably built Python 3.0 from source and used the Ubuntu default Python install for comparison: The default Python 3.0 build will create a UCS2 unless you specify the --enable-unicode=ucs4 configure option. The Ubuntu Python build (like many other Linux distros) uses this option per default. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:42:22 2008 From: report at bugs.python.org (Alex Roper) Date: Tue, 16 Dec 2008 23:42:22 +0000 Subject: [issue4679] Fork + shelve causes shelve corruption and backtrace In-Reply-To: <1229470942.41.0.397425864374.issue4679@psf.upfronthosting.co.za> Message-ID: <1229470942.41.0.397425864374.issue4679@psf.upfronthosting.co.za> New submission from Alex Roper : Hi, I wrote a simple script (attached) to do some preprocessing of MediaWiki XML dumps. When it has a 8 MB chunk ready to dump to disk, it forks, and the child writes it out and (will) compress it, then exit. The main thread continues as before. Note that the child thread never touches (or executes code that has in scope) the shelve handle. The attached script, as written, will work fine on dumps (I tested it on enwikisource-20081112-pages-articles.xml available from http://download.wikimedia.org/enwikisource/20081112/). If you uncomment the fork on line 40 (and the exit() on line 46 of course) and run it, it will die after writing out about 450 megabytes with the backtrace below. This appears to happen deterministically at the same place 3 of the 3 times I ran it. Apologies for the size and complexity of the test, I don't have time to reduce it further at the moment, and it looks like it may be fairly involved. I can try to work out a reduced case later and resubmit if no one wants to touch this as is;) # I ran the script with: bzcat enwikisource-20081112-pages-articles.xml.bz2 | ./convert.py wikisource 8388608 # (after making a dir called wikisource) Let me know if I can be of any assistance, and apologies if this is somewhere documented and I missed it. Using Python 2.6.1 as released from python.org. Alex alexr at autumn:~/projects/wikipedia$ cat enwikisource-20081112-pages-articles.xml | ./convert.py wikisource 8388608 Alexandria version 1, Copyright (C) 2008 Alex Roper Alexandria comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to copy modify, and redistribute it under certain conditions; see the file COPYING for details. ..........................................................Traceback (most recent call last): File "./convert.py", line 100, in sax.parse(sys.stdin, Parser(sys.argv[1], MIN_CHUNK_SIZE)) File "/usr/lib/python2.6/xml/sax/__init__.py", line 33, in parse parser.parse(source) File "/usr/lib/python2.6/xml/sax/expatreader.py", line 107, in parse xmlreader.IncrementalParser.parse(self, source) File "/usr/lib/python2.6/xml/sax/xmlreader.py", line 123, in parse self.feed(buffer) File "/usr/lib/python2.6/xml/sax/expatreader.py", line 207, in feed self._parser.Parse(data, isFinal) File "/usr/lib/python2.6/xml/sax/expatreader.py", line 304, in end_element self._cont_handler.endElement(name) File "./convert.py", line 61, in endElement s.pagehandler(s.title, s.text) File "./convert.py", line 68, in pagehandler s.index[title.encode("UTF8")] = (s.chunks, len(s.pages)) File "/usr/lib/python2.6/shelve.py", line 133, in __setitem__ self.dict[key] = f.getvalue() File "/usr/lib/python2.6/bsddb/__init__.py", line 276, in __setitem__ _DeadlockWrap(wrapF) # self.db[key] = value File "/usr/lib/python2.6/bsddb/dbutils.py", line 68, in DeadlockWrap return function(*_args, **_kwargs) File "/usr/lib/python2.6/bsddb/__init__.py", line 275, in wrapF self.db[key] = value bsddb.db.DBRunRecoveryError: (-30975, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb.db.DBRunRecoveryError: DBRunRecoveryError(-30975, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: fatal region error detected; run recovery') in > ignored Exception bsddb.db.DBRunRecoveryError: DBRunRecoveryError(-30975, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: fatal region error detected; run recovery') in ignored Exception bsddb.db.DBRunRecoveryError: DBRunRecoveryError(-30975, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: fatal region error detected; run recovery') in ignored ---------- components: Extension Modules files: convert.py messages: 77942 nosy: calmofthestorm severity: normal status: open title: Fork + shelve causes shelve corruption and backtrace type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12370/convert.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:50:18 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Dec 2008 23:50:18 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229471418.03.0.694602751862.issue2183@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This looks like a major improvement, not just for speed, but for getting rid of the _[1] arguments setup, retrieval, and deletion. I presume it has been tested with nested and conditional variants? def f(): return [x for t in s for x in t if x] ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:53:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 16 Dec 2008 23:53:14 +0000 Subject: [issue4678] Unicode: multiple chars for high code points In-Reply-To: <1229469924.95.0.71145202333.issue4678@psf.upfronthosting.co.za> Message-ID: <1229471594.68.0.234223723439.issue4678@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As Mark-Andre say, this is not a bug. Finding out the exact name of the configure option is left as an exercise. ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:58:26 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 16 Dec 2008 23:58:26 +0000 Subject: [issue4678] Unicode: multiple chars for high code points In-Reply-To: <1229471594.68.0.234223723439.issue4678@psf.upfronthosting.co.za> Message-ID: <494840A0.7060308@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-17 00:53, Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > As Marc-Andre say, this is not a bug. Finding out the exact name of the > configure option is left as an exercise. Ah, so that changed as well... for Python 3.0 it's called --with-wide-unicode. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:58:41 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2008 23:58:41 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1229471418.03.0.694602751862.issue2183@psf.upfronthosting.co.za> Message-ID: <1229471914.7296.34.camel@localhost> Antoine Pitrou added the comment: > I presume it has been tested with nested and conditional variants? The whole test suite runs fine. test_iter and test_grammar seem to cover all possible cases. As for performance, the new benches in #4677 show a moderate improvement (~ 10%). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:02:48 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2008 00:02:48 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229472168.32.0.907462890378.issue2183@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is a nice cleanup. Marking as accepted. Go ahead and apply. ---------- assignee: nnorwitz -> pitrou resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:17:55 2008 From: report at bugs.python.org (Mihai Ibanescu) Date: Wed, 17 Dec 2008 00:17:55 +0000 Subject: [issue4675] urllib's splitpasswd does not accept newline chars in passwords In-Reply-To: <1229455632.0.0.358250268025.issue4675@psf.upfronthosting.co.za> Message-ID: <1229473075.74.0.783499603796.issue4675@psf.upfronthosting.co.za> Changes by Mihai Ibanescu : ---------- keywords: +patch Added file: http://bugs.python.org/file12371/splitpasswd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:24:10 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 17 Dec 2008 00:24:10 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229473450.61.0.733149969738.issue4653@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: It's difficult to really test such errors. Moreover, on the top of the bdist_wininst files, a comment says loudly: IF CHANGES TO THIS FILE ARE CHECKED INTO PYTHON CVS, THE RECOMPILED BINARIES MUST BE CHECKED IN AS WELL! ---------- nosy: +amaury.forgeotdarc, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:27:22 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Wed, 17 Dec 2008 00:27:22 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229473642.16.0.94196556606.issue2183@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : ---------- nosy: +jyasskin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:39:17 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 00:39:17 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229474357.22.0.397283975819.issue2183@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've fixed the Python compiler package and committed it all in r67818. Will port to py3k. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 02:45:57 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 01:45:57 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1229474357.22.0.397283975819.issue2183@psf.upfronthosting.co.za> Message-ID: <1229478350.7296.36.camel@localhost> Antoine Pitrou added the comment: I have started porting to py3k and I've applied the same optimizations to set and dict comprehensions. I just have a question: I have created an opcode MAP_ADD which is very similar to STORE_MAP, except that it takes as argument the stack offset to the dict object. Should I merge the two opcodes together? (STORE_MAP would be replaced with MAP_ADD(0), as it takes its dict from the top of the stack). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 02:50:48 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 01:50:48 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229478648.5.0.296038392696.issue2183@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, here's the py3k patch. ---------- versions: -Python 2.7 Added file: http://bugs.python.org/file12372/py3k-comps.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 02:57:12 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2008 01:57:12 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229479032.51.0.520772764747.issue2183@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Will take a look in the morning and get back to you on the MAP_ADD question. ---------- assignee: pitrou -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:05:05 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 17 Dec 2008 02:05:05 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229479505.59.0.0755161175343.issue1524639@psf.upfronthosting.co.za> Guilherme Polo added the comment: Something like the proposed patch is still needed. But allow me to point out my views towards your current patch: * Changes in Misc.after, Misc._bind: good * Changes in Misc.unbind can be simplified a bit: cbs = self._bind_names(self._bind(('bind', self._w), sequence, func=None, add=None)) could be only: cbs = self._bind_names(self.bind(sequence)) and the comment in the end should go. * Changes in Misc.unbind_all and Misc.unbind_class can be simplified in the same as as Misc.unbind (just change self.bind by self.bind_all and self.bind_class) * Changes in Variable: would you care to elaborate more on these ? Do you need a new _tclCommands there and also use the _tclCommands from its master ? * Changes in Misc._options are somewhat fine. - The comment about Python 2.3, 2.4, 2.5 being bugged because a Tcl_Obj is returned is misleading, so you should change it. - What are you gaining by sorting the cnf keys ? * Changes in Misc._configure uhm.. it is hard to like that one =) Since we are after commands created, why can't we just check the _tclCommands before and after calling tcl here ? So we just remove the difference (maybe move it to a set?) and don't do all those checks in case of error, and then reraise the error. * Changes in Wm.wm_protocol: I almost like it, except that there are two checks for a callable arg now. Hopefully you are still around. ---------- nosy: +gpolo versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:48:06 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 17 Dec 2008 02:48:06 +0000 Subject: [issue1731706] tkinter memory leak problem Message-ID: <1229482086.39.0.470743715697.issue1731706@psf.upfronthosting.co.za> Guilherme Polo added the comment: Sample attached for demonstrating the leak by missing a call to Tkapp_CallDeallocArgs. ---------- nosy: +gpolo Added file: http://bugs.python.org/file12373/test_tkleak1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 04:06:40 2008 From: report at bugs.python.org (Roy Smith) Date: Wed, 17 Dec 2008 03:06:40 +0000 Subject: [issue4680] Queue class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> New submission from Roy Smith : It would be nice if Queue.Queue included a way to access the high-water mark, i.e. the largest value which qsize() has ever reached. This is often useful when assessing application performance. I am assuming this is cheap, i.e. O(1), to provide. ---------- components: Library (Lib) messages: 77955 nosy: roysmith severity: normal status: open title: Queue class should include high-water mark type: feature request versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 04:25:51 2008 From: report at bugs.python.org (Collin Winter) Date: Wed, 17 Dec 2008 03:25:51 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229484351.91.0.0351077468893.issue4074@psf.upfronthosting.co.za> Changes by Collin Winter : ---------- nosy: +collinwinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 04:29:38 2008 From: report at bugs.python.org (David W. Lambert) Date: Wed, 17 Dec 2008 03:29:38 +0000 Subject: [issue4680] Queue class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229484578.78.0.0779764721119.issue4680@psf.upfronthosting.co.za> Changes by David W. Lambert : ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 06:50:10 2008 From: report at bugs.python.org (Johnny Lee) Date: Wed, 17 Dec 2008 05:50:10 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229493010.11.0.95674500019.issue4653@psf.upfronthosting.co.za> Changes by Johnny Lee : Removed file: http://bugs.python.org/file12335/py30diff.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 06:52:06 2008 From: report at bugs.python.org (Johnny Lee) Date: Wed, 17 Dec 2008 05:52:06 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229493126.97.0.674201839102.issue4653@psf.upfronthosting.co.za> Johnny Lee added the comment: attached modified diff patch so line length <=79 chars Added file: http://bugs.python.org/file12374/py30dif2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 07:04:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 17 Dec 2008 06:04:25 +0000 Subject: [issue4680] Queue class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229493865.33.0.0399342785455.issue4680@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: +Python 2.7 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 09:40:10 2008 From: report at bugs.python.org (saa) Date: Wed, 17 Dec 2008 08:40:10 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> New submission from saa : In trying to use the mmap offset to allow me to work with a 12GB file, I encountered the fact that the new offset parameter was a ssize_t, which is only 32 bits on my platform (OS X). The mmap offset in C is defined to be an off_t (http://opengroup.org/onlinepubs/007908775/xsh/mmap.html), which is 64 bits on my platform. The attached patch attempts to fix the non-Windows code to have an off_t offset parameter and allows my code to access all 12 GB of my file. As a warning, this is the first time I've even looked at the Python source, and wouldn't even consider myself a Python coder; I just use Python every few months. Review the patch carefully. ---------- components: Extension Modules files: mmap_off_t.patch keywords: patch messages: 77957 nosy: saa severity: normal status: open title: mmap offset should be off_t instead of ssize_t type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12375/mmap_off_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 10:07:10 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 17 Dec 2008 09:07:10 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229504830.07.0.282958248519.issue4681@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't think fpos_t is a suitable type here. It isn't guaranteed to be an integral type, and, on many systems, it isn't integral. So you can't convert int to it, and you can't do arithmetic on it. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 10:17:41 2008 From: report at bugs.python.org (saa) Date: Wed, 17 Dec 2008 09:17:41 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229505461.37.0.721189112554.issue4681@psf.upfronthosting.co.za> saa added the comment: Sorry, I should have explained that the bulk of my patch was derived from existing code. The code that references fpos_t is basically a cut and paste of code from Modules/bz2module.c. I don't know if this is a valid usage of fpos_t, but if it isn't, you should probably file a bug on the existing usage in bz2module and suggest a fix. Thanks for reviewing! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 10:38:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 17 Dec 2008 09:38:25 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229506705.59.0.323046514694.issue4681@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is different from bz2, though. In bzlib, there is no API to seek to a certain position. In mmap, the offset type in mmap specified as off_t, so fpos_t plays no role here. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 10:42:28 2008 From: report at bugs.python.org (saa) Date: Wed, 17 Dec 2008 09:42:28 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229506948.3.0.903005524381.issue4681@psf.upfronthosting.co.za> saa added the comment: Ah, I think I'm beginning to understand. Thanks for the explanation. So, if I understand correctly, I should refactor the patch and just remove all of the Py_off_t and just use off_t because the standard says that *is* the type. Correct? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 10:45:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 17 Dec 2008 09:45:52 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t In-Reply-To: <1229506948.3.0.903005524381.issue4681@psf.upfronthosting.co.za> Message-ID: <4948CA4E.8010107@v.loewis.de> Martin v. L?wis added the comment: > Ah, I think I'm beginning to understand. Thanks for the explanation. So, > if I understand correctly, I should refactor the patch and just remove all > of the Py_off_t and just use off_t because the standard says that *is* the > type. Correct? Correct. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 10:55:49 2008 From: report at bugs.python.org (saa) Date: Wed, 17 Dec 2008 09:55:49 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229507749.54.0.237245506047.issue4681@psf.upfronthosting.co.za> saa added the comment: Thanks again, revised patch attached. Added file: http://bugs.python.org/file12376/mmap_off_t_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 12:02:19 2008 From: report at bugs.python.org (vt) Date: Wed, 17 Dec 2008 11:02:19 +0000 Subject: [issue4682] 'b' formatter is actually unsigned char In-Reply-To: <1229511739.0.0.626057427861.issue4682@psf.upfronthosting.co.za> Message-ID: <1229511739.0.0.626057427861.issue4682@psf.upfronthosting.co.za> New submission from vt : The 'b' format unit to PyArg_ParseTuple, PyArg_ParseTupleAndKeywords, and PyArg_Parse is described in the documentation (in Parsing arguments and building values) as representing a signed char, but actually represents an unsigned char. Personally, I would say that this is a problem with the interpreter core, but 'b' has been an unsigned char since 2000 and fixing it now would probably break backwards compatibility of extensions. ---------- assignee: georg.brandl components: Documentation messages: 77964 nosy: georg.brandl, vt severity: normal status: open title: 'b' formatter is actually unsigned char _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:14:21 2008 From: report at bugs.python.org (Chris Boyle) Date: Wed, 17 Dec 2008 14:14:21 +0000 Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname? In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za> Message-ID: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za> New submission from Chris Boyle : The attached script, when edited to fill in valid LiveJournal credentials (or InsaneJournal, if you change the URL and user list) fails for me in a very odd way. It fetches the first two URLs quite happily, and returns a 401 on the third after querying my password manager about 6 times (always the third, no matter what the user list is). Rebuilding the opener each time around the loop doesn't fix it. Recreating the HTTPDigestAuthHandler (and then rebuilding the opener) *does* fix it. Seems like any given instance of HTTPDigestAuthHandler fails on the third hostname. Python package version 2.5.1-5ubuntu5.2. Haven't tried it on newer versions. ---------- components: Extension Modules files: urllib2-test.txt messages: 77965 nosy: cmb severity: normal status: open title: urllib2.HTTPDigestAuthHandler fails on third hostname? type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file12377/urllib2-test.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 16:00:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 15:00:35 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229526035.73.0.973399741014.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch adds another improvement where tuples can be "optimized". Optimized means that tuples which don't contain any GC-tracked object become themselves untracked. Since tuples are immutable this optimization is valid, and since it is common to store lots of tuples as very simple containers of atomic objects this can be an interesting optimization. Added file: http://bugs.python.org/file12378/gctrigger2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 16:21:13 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 15:21:13 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229527273.8.0.177245447541.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch also adds a function named gc.is_tracked() which returns True if the object is tracked by the GC: >>> import gc >>> gc.is_tracked(1) False >>> gc.is_tracked([]) True >>> gc.is_tracked(()) True >>> gc.is_tracked((0,1)) False >>> gc.is_tracked((0,"a")) False >>> gc.is_tracked((0,[])) True >>> gc.is_tracked((0,(1,2))) False >>> gc.is_tracked((0,(1,0.55))) False >>> gc.is_tracked((0,(1,{}))) True >>> gc.is_tracked((None, True, False, "a", (1,2,u"z",("another", "nested", u"tuple")), int)) False >>> gc.is_tracked(gc) True (as you see the empty tuple is considered tracked, this is not important since it is a singleton anyway) Added file: http://bugs.python.org/file12379/gctrigger3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 16:34:50 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 17 Dec 2008 15:34:50 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229528090.78.0.771585904932.issue1524639@psf.upfronthosting.co.za> Guilherme Polo added the comment: The changes in Misc.destroy do not look right, why are you deleting commands created by bind_all (for example) from the root window when a simple widget is destroyed ? It would make more sense to not apply these changes in Misc.destroy, instead, Misc.unbind_all would remove commands from the root using Misc._root.deletecommand and inside Misc._bind it would check if needcleanup is true or false and decide from where to remove. Also, given how this needcleanup parameter is used, I suggest renaming it to widgetcmd, so if it is set 0 it indicates that the command should live in self._root()._tclCommands. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 16:43:18 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 17 Dec 2008 15:43:18 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229528598.48.0.256952479232.issue3439@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- nosy: -skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 17:18:40 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Wed, 17 Dec 2008 16:18:40 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229530720.55.0.020432262429.issue1524639@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: A little remark : please replace "if not globals().has_key('TkinterError'):" by "if 'TkinterError' not in globals():". has_key is now deprecated in 2.6 and should be avoided. ---------- nosy: +quentin.gallet-gilles versions: -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 17:20:53 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 17 Dec 2008 16:20:53 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229530853.72.0.68943702418.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: Committed to trunk in r67822, py3k in r67824. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 17:26:35 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 17 Dec 2008 16:26:35 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229531195.01.0.131612637028.issue1524639@psf.upfronthosting.co.za> Guilherme Polo added the comment: Fix: My previous comment was about changes in Misc.deletecommand not Misc.destroy (this is what you get for guessing the methods changed in the diff, without applying it). To Quentin: I wouldn't bother mentioning it since this new TkinterError exception should go away along the changes in Misc.deletecommand as mentioned in my previous comment. ---------- versions: +Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 17:40:58 2008 From: report at bugs.python.org (Nicolau Leal Werneck) Date: Wed, 17 Dec 2008 16:40:58 +0000 Subject: [issue1170] shlex have problems with parsing unicode In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za> Message-ID: <1229532058.41.0.0348852762405.issue1170@psf.upfronthosting.co.za> Nicolau Leal Werneck added the comment: Hello. I tried to patch my own shlex, and this doens't seem to be working properly. When I try the patched module isntead of th eoriginal, in my otherwise working program, I get the result ahead. Is there any conversion steps missing?... mymachine$ python interp.py < exemplo.prg Traceback (most recent call last): File "interp.py", line 11, in tok = ss.get_token() File "shlexutf.py", line 103, in get_token raw = self.read_token() File "shlexutf.py", line 139, in read_token nextcategory = unicodedata.category(nextchar) TypeError: category() argument 1 must be unicode, not str ---------- nosy: +nwerneck _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 18:12:21 2008 From: report at bugs.python.org (Nicolau Leal Werneck) Date: Wed, 17 Dec 2008 17:12:21 +0000 Subject: [issue1170] shlex have problems with parsing unicode In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za> Message-ID: <1229533941.48.0.162714406434.issue1170@psf.upfronthosting.co.za> Nicolau Leal Werneck added the comment: OK, it worked after I found out I didn't know how to open unicode files... Sorry for the noise, and thanks for this patch! :] _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 18:18:54 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 17:18:54 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229534334.63.0.540593168697.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a new patch adding tests for gc.is_tracked(). Added file: http://bugs.python.org/file12380/gctrigger4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 18:20:22 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 17:20:22 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229534422.24.0.567878934591.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, with the tuple optimization, the number of objects in gc.get_objects() after the regression tests has fallen from 150000 to 140000. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 18:48:00 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 17:48:00 +0000 Subject: [issue4680] Queue class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229536080.37.0.993749202705.issue4680@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It is probably easy enough to do so in a custom Queue subclass, and it's too specialized to put in the standard library IMHO. I'm closing the bug, another developer can reopen it if he thinks it is truely useful. ---------- nosy: +pitrou resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 18:51:18 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 17 Dec 2008 17:51:18 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229536278.67.0.482183308094.issue1524639@psf.upfronthosting.co.za> Guilherme Polo added the comment: Rethinking about the changes done in Misc._configure I found out that you don't need any of those there. Isn't it the case of only improving the changes regarding callable overwriting in Misc._options ? So if the value is a callable and the option doesn't exist you also don't _register the callable. Maybe I'm forgetting about something here, so you could bring an example that fails on this reasoning. I've applied these changes and others commented before in a thing I'm testing: http://code.google.com/p/plumage/source/detail?r=85 http://code.google.com/p/plumage/source/detail?r=86 http://code.google.com/p/plumage/source/detail?r=87 http://code.google.com/p/plumage/source/detail?r=89 http://code.google.com/p/plumage/source/detail?r=91 I didn't fix the ones related to Variable yet, but if any of these changes looks fine for someone the diffs would probably apply on "the standard" Tkinter.py without much problem. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 18:59:08 2008 From: report at bugs.python.org (Mark Florisson) Date: Wed, 17 Dec 2008 17:59:08 +0000 Subject: [issue4684] sys.exit() exits program when non-daemonic threads are still running In-Reply-To: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za> Message-ID: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za> New submission from Mark Florisson : sys.exit() exits the program when non-daemonic threads are still running, in versions >= 2.5. Test included. A demonstration here: http://paste.pocoo.org/show/95766/ (On debian GNU/Linux) ---------- components: None files: foo.py messages: 77978 nosy: eggy severity: normal status: open title: sys.exit() exits program when non-daemonic threads are still running type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file12381/foo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 18:59:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2008 17:59:13 +0000 Subject: [issue4680] Queue class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229536753.42.0.901054063512.issue4680@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with Antoine. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 19:44:07 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2008 18:44:07 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229539447.36.0.161973532061.issue3439@psf.upfronthosting.co.za> STINNER Victor added the comment: > Committed Really? YEAH! Great job everybody ;-) I read the code and it looks valid. Micro optimisation (for smaller memory footprint): would it be possible to share the 32 int table (BitLengthTable) between int and long (in Python 2.x)? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 20:09:40 2008 From: report at bugs.python.org (osvenskan) Date: Wed, 17 Dec 2008 19:09:40 +0000 Subject: [issue3110] Multiprocessing package build problem on Solaris 10 In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za> Message-ID: <1229540980.42.0.8906663612.issue3110@psf.upfronthosting.co.za> Changes by osvenskan : ---------- nosy: +osvenskan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 20:49:52 2008 From: report at bugs.python.org (Roy Smith) Date: Wed, 17 Dec 2008 19:49:52 +0000 Subject: [issue4680] Queue class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229543392.15.0.617798556962.issue4680@psf.upfronthosting.co.za> Roy Smith added the comment: I'm suppose you could implement this in a subclass, but it would be inefficient. You'd have to over-ride put() and get(), call qsize(), then delegate to Base.put() and Base.get(). A cleaner solution would be in the C implementation of deque, in Modules/collectionsmodule.c. There's just a couple of places where queue->len gets incremented. All that needs to happen is add: if (queue->len > queue->high_water_mark) { queue->high_water_mark = queue->len; } after each one and then add the appropriate accessor functions in deque and Queue to expose it to users. The run-time cost is a couple of machine instructions for each item added to the deque. If I were to write the code and submit it, would you be willing to accept it? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 20:57:48 2008 From: report at bugs.python.org (Ilan) Date: Wed, 17 Dec 2008 19:57:48 +0000 Subject: [issue4685] IDLE will not open (2.6.1 on WinXP pro) In-Reply-To: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za> Message-ID: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za> New submission from Ilan : Hello, I am new to programming... I installed Python a couple days ago with no problems. I used it quite a bit since I'm going through loads of tutorials. All of a sudden, it shut off, closed and will no longer open. This problem seems to be common, but none of the suggestions work. I uninstalled it and re-installed it to no avail. The command line works however. Suggestions? ---------- components: IDLE messages: 77982 nosy: Yo severity: normal status: open title: IDLE will not open (2.6.1 on WinXP pro) versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 21:22:42 2008 From: report at bugs.python.org (David M. Beazley) Date: Wed, 17 Dec 2008 20:22:42 +0000 Subject: [issue4686] Exceptions in ConfigParser don't set .args In-Reply-To: <1229545362.85.0.86911392572.issue4686@psf.upfronthosting.co.za> Message-ID: <1229545362.85.0.86911392572.issue4686@psf.upfronthosting.co.za> New submission from David M. Beazley : The ConfigParser module defines a variety of custom exceptions, many of which take more than one argument (e.g., InterpolationError, NoOptionError, etc.). However, none of these exceptions properly set the .args attribute. For example, shouldn't NoOptionError be defined as follows: class NoOptionError(Error): def __init__(self,option,section): Error.__init__(self,"No option %r in section: %r" % (option,section)) self.option = option self.section = section self.args = (option,section) #!! Added this line This is kind of a minor point, but the missing args means that these exceptions don't work properly with programs that need to do fancy kinds of exception processing (i.e., catching errors and reraising them in a different context or process). I can't speak for Python 3.0, but it's my understanding that .args should always be set to the exception arguments. Don't ask how I came across this---it was the source of a really bizarre bug in something I was playing around with. ---------- components: Library (Lib) messages: 77983 nosy: beazley severity: normal status: open title: Exceptions in ConfigParser don't set .args type: behavior versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:23:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2008 21:23:37 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229549017.14.0.115426519862.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: 32 bytes isn't worth sharing between modules. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:23:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 21:23:39 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229549019.01.0.706941641347.issue4074@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file11743/tuple_gc_hell.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:24:14 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 21:24:14 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229549054.58.0.929388650253.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New version of Greg's script, with different choices (list of tuples, list of lists, list of dicts, dict of tuples). Added file: http://bugs.python.org/file12382/tuple_gc_hell.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:33:43 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2008 21:33:43 +0000 Subject: [issue4680] deque class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229549623.86.0.639598449933.issue4680@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Will think about it for a bit. My initial inclination is against because there have been no other such requests to instrument all the fundamental data types, because it's not hard to add instrumentation using your own pure python additions around size-mutating calls, because it clutters the API, and because it's unclear whether a maximum-size statistic has much utility. For deques, should the clear() method zero-out the high-water mark? How about the equivalent code where the contents are all popped-off (down to zero size) before the structure is re-used? ---------- assignee: -> rhettinger title: Queue class should include high-water mark -> deque class should include high-water mark _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:36:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 21:36:42 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229549802.81.0.274432088123.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Now an additional patch which applies over the basic gctrigger4.patch. It adds dict optimizations so that dicts with only atomic or immutable elements are also untracked (they get tracked later when other trackable elements are added). Since dicts are often used as mappings of simple objects (int, str, tuple) over other simple objects, this can be very useful. Added file: http://bugs.python.org/file12383/dictopts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:44:33 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 17 Dec 2008 21:44:33 +0000 Subject: [issue4397] test_socket fails occassionaly in teardown: AssertionError: [Errno 57] Socket is not connected In-Reply-To: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za> Message-ID: <1229550273.99.0.143068922247.issue4397@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the report. I can reproduce this both on the py3k branch and the trunk. It looks as though there's a race condition in the testShutDown/_testShutDown pair of methods in SocketConnectedTest. If you add the line time.sleep(0.01) to the middle of the _testShutDown method in test_socket.py (between the self.serv_conn.send() and the self.serv_conn.shutdown), you'll probably find that this random occasional failure becomes a 99.9% reliable failure. As far as I can tell, this is just a bug in test_socket itself, rather than a problem with the socket module. I also can't see any reason why it should be Mac specific, but I don't have anything else handy to test on right now. Suggested fix: don't let testShutDown exit until after _testShutdown has executed the shutdown method. Use a threading Event to make this work. The attached patch (against the trunk) appears to fix the problem for me. Martina, if you're in a position to test the patch, feedback would be welcome. It would be good if someone could review this for sanity; I'm a complete novice when it comes to threading (and sockets, for that matter). ---------- components: -Library (Lib), Macintosh keywords: +patch nosy: +marketdickinson priority: -> normal stage: -> patch review versions: +Python 2.6, Python 2.7, Python 3.1 Added file: http://bugs.python.org/file12384/issue4397.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 23:05:46 2008 From: report at bugs.python.org (Roy Smith) Date: Wed, 17 Dec 2008 22:05:46 +0000 Subject: [issue4680] deque class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229551546.26.0.454791415763.issue4680@psf.upfronthosting.co.za> Roy Smith added the comment: I'm not actually sure what the use case is for clear(). It's easy enough to just create a new deque. If you can do that, why do you need clear()? Since I don't ever see a reason anybody would want to call clear(), I'm not 100% if it should reset the high-water mark or not. I don't *think* it should, but I'm willing to believe that a use case could exist which would make me change my mind about that. Popping all the elements off the deque certainly should *not* reset the high water mark. The whole point of tracking the high water mark is to know if the consumer thread ever fell behind the producer thread (yes, I realize queues could be used for non-threading purposes). It's perfectly normal for the queue to drain completely at times, and there's absolutely no reason this should affect the high-water mark. You do raise a good question about whether all of the standard containers should be instrumented. I don't know the answer to that. Queues and, say, dicts are different beasts. It's common to use queues where the putting-in and taking-out are asynchronous, and thus the high-water mark is an indicator of overall application health. I don't see that for dicts, or lists (well, maybe if used as a stack) or most other kinds of containers. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 23:20:34 2008 From: report at bugs.python.org (darrenr) Date: Wed, 17 Dec 2008 22:20:34 +0000 Subject: [issue4273] cycle created by profile.run In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> Message-ID: <1229552434.21.0.237258123286.issue4273@psf.upfronthosting.co.za> darrenr added the comment: I think we still need to prevent collectable cycles in our Python code. Here's the situation: We've got a process that creates many Python objects, and it needs to be responsive, it's not good for it to block on one operation for more than 100-200 ms. The automatic garbage collection is currently taking on the order of 2 seconds for this process. If we can guarantee that no collectable or non-collectable cycles are being created, we can gradually increase the collection threshold, or turn off the garbage collector entirely, reducing or eliminating the blocking overhead of garbage collection. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 23:51:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 22:51:07 +0000 Subject: [issue2467] gc.DEBUG_STATS reports invalid "elapsed" times In-Reply-To: <1206294574.77.0.365865271112.issue2467@psf.upfronthosting.co.za> Message-ID: <1229554267.75.0.927772817603.issue2467@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed in r67832, thanks! ---------- nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 2.7 -Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:03:39 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 17 Dec 2008 23:03:39 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229555019.03.0.976641843758.issue1524639@psf.upfronthosting.co.za> Guilherme Polo added the comment: I've fixed the leaks in Variable doing this: http://code.google.com/p/plumage/source/detail?r=93 I don't use an extra _tclCommands for Variable, instead in __del__ I use the information returned by Variable.trace_vinfo to remove associated callbacks. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:06:19 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:06:19 +0000 Subject: [issue4687] GC stats not accurate because of debug overhead In-Reply-To: <1229555179.58.0.313721223376.issue4687@psf.upfronthosting.co.za> Message-ID: <1229555179.58.0.313721223376.issue4687@psf.upfronthosting.co.za> New submission from Antoine Pitrou : With gc.DEBUG_STATS, each GC collection displays the elapsed time. Unfortunately, this elapsed time includes the debug overhead itself, most notable the calls to gc_list_size() which can be quite expensive with lots of objects in the older generation. Consequently, collections of generation 0 will incorrectly appear as very expensive, while in non-debug mode they are very cheap. Here is a patch to get a more useful output, by not including the time taken in gc_list_size(). ---------- components: Extension Modules files: gc_stats_fix.patch keywords: patch messages: 77993 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: GC stats not accurate because of debug overhead type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file12385/gc_stats_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:35:54 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:35:54 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229556954.53.0.147322000586.issue4074@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12383/dictopts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:35:58 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:35:58 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229556958.33.0.786901328318.issue4074@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12353/gctrigger.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:36:01 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:36:01 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229556961.07.0.0114173686366.issue4074@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12378/gctrigger2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:36:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:36:04 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229556964.1.0.0738694675024.issue4074@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12379/gctrigger3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:36:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:36:07 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229556967.08.0.737011274504.issue4074@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12380/gctrigger4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:36:57 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:36:57 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229557017.41.0.756497737954.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Cleanup: this patch only has the algorithmic change. Tuple and dict opts will go to a separate tracker issue. Added file: http://bugs.python.org/file12386/gctrigger5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:41:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:41:09 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Split out from #4074, here is a standalone patch which disables GC tracking for simple tuples (tuples made of atomic objects or immutable containers, possibly nested). The performance improvement can be evaluated using tuple_gc_hell.py from #4074. The patch also adds a function named is_tracked() to the gc module. ---------- components: Interpreter Core files: tupleopts.patch keywords: patch messages: 77995 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: GC optimization: don't track simple tuples and dicts type: performance versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file12387/tupleopts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:48:48 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:48:48 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229557728.54.0.305110483406.issue4688@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This additional patch also optimizes simple dicts, it must be applied over the tuples patch. Together these two patches make it so that e.g. a dict of tuples or strings won't be tracked at all, saving CPU cycles when collecting. ---------- nosy: +loewis Added file: http://bugs.python.org/file12388/dictopts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:49:27 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 17 Dec 2008 23:49:27 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1229557767.82.0.867403089998.issue4074@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The optimization issue for tuples and dicts is #4688. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:53:33 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2008 23:53:33 +0000 Subject: [issue4680] deque class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229558013.74.0.15000767127.issue4680@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, here's a trivial Queue subclass with instrumentation: class HighWaterQueue(Queue): def _init(self, maxsize): Queue.__init__(self, maxsize) self.highwater = 0 def _put(self, item): Queue._put(self, item) self.highwater = max(self.highwater, self._qsize()) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:56:57 2008 From: report at bugs.python.org (Daniel Stutzbach) Date: Wed, 17 Dec 2008 23:56:57 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229558217.63.0.0499235074943.issue4688@psf.upfronthosting.co.za> Daniel Stutzbach added the comment: I've looked very quickly over your patches to try to figure what rule qualifies a tuple or dict as simple enough to be untracked, out of curiosity. For tuples, I think the rule is: If an object is immutable, and it points only to untracked objects, the object can be untracked. Is that right? If so, you could perform the same optimization on the frozenset() type. Why do empty tuples have to be tracked? The dict patch adds a boolean flag to the dict data structure to indicate whether the dict is being tracked or not. I think. Couldn't you use _PyObject_GC_IS_TRACKED() instead? What's the rule for when a dict can be tracked or untracked? Do you need to recheck the rule every time the dict is modified? ---------- nosy: +stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:57:03 2008 From: report at bugs.python.org (Mark Evans) Date: Wed, 17 Dec 2008 23:57:03 +0000 Subject: [issue4689] Typo in PyObjC URL on "GUI Programming on the Mac" In-Reply-To: <1229558222.99.0.886125304786.issue4689@psf.upfronthosting.co.za> Message-ID: <1229558222.99.0.886125304786.issue4689@psf.upfronthosting.co.za> New submission from Mark Evans : The "GUI Programming on the Mac" page: http://www.python.org/doc/2.5.3/mac/node10.html states that the PyObjC project is at: http://pybojc.sourceforge.net This is incorrect and should be: http://pyobjc.sourceforge.net This appears fixed in the 2.6 and 3.0 documentation. ---------- assignee: georg.brandl components: Documentation messages: 78000 nosy: georg.brandl, mevans severity: normal status: open title: Typo in PyObjC URL on "GUI Programming on the Mac" versions: Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:04:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 00:04:56 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229558217.63.0.0499235074943.issue4688@psf.upfronthosting.co.za> Message-ID: <1229558691.10561.9.camel@localhost> Antoine Pitrou added the comment: Le mercredi 17 d?cembre 2008 ? 23:56 +0000, Daniel Stutzbach a ?crit : > For tuples, I think the rule is: > If an object is immutable, and it points only to untracked objects, > the object can be untracked. Roughly, yes. Exactly, it is "if it points only to untrackable objects". That is, a tuple containing an untracked dict will still be tracked, because the dict may mutate and become tracked later. But a tuple containing an untracked tuple will itself be untracked, because the enclosed tuple can't mutate. > Is that right? If so, you could perform the same optimization on the > frozenset() type. Yes, but I prefer to concentrate on those two core types now, which are the most frequent. Once the principle is accepted we can extend the implementation to other types. > Why do empty tuples have to be tracked? Actually, they are never tracked, which means calling _PyObject_GC_UNTRACK on them would segfault. > The dict patch adds a boolean flag to the dict data structure to > indicate whether the dict is being tracked or not. I think. Couldn't > you use _PyObject_GC_IS_TRACKED() instead? Yes, probably. I thought a dedicated flag may be faster but I will try without. > Do you > need to recheck the rule every time the dict is modified? Only if it is not tracked. Once a dict is tracked, it cannot become untracked again (there would be too much overhead, and the assumption is that you usually create homogeneous containers, you don't create a dict of mutable containers things and then replace the mutable containers with simple atomic objects). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:12:03 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 18 Dec 2008 00:12:03 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229559123.65.0.326011978999.issue4688@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:15:46 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 00:15:46 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229559346.35.0.404487688429.issue4688@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So, I've tried without the dedicated flag in the dict object and it's as fast as previously! Here is a new patch. Added file: http://bugs.python.org/file12389/dictopts2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:19:23 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 00:19:23 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229559563.64.0.855636145653.issue4688@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12388/dictopts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:32:02 2008 From: report at bugs.python.org (Forest Wilkinson) Date: Thu, 18 Dec 2008 00:32:02 +0000 Subject: [issue4690] asyncore calls handle_write() on closed sockets when use_poll=True In-Reply-To: <1229560322.27.0.660252722227.issue4690@psf.upfronthosting.co.za> Message-ID: <1229560322.27.0.660252722227.issue4690@psf.upfronthosting.co.za> New submission from Forest Wilkinson : With use_poll=True on linux, asyncore calls handle_write() after the socket has been closed. More specifically, it looks like asyncore dispatches handle_read() and handle_close() events between the writable() test and the corresponding handle_write() call. If handle_close() calls close(), as asyncore's default implementation does, the subsequent handle_write() will fail and generate an EBADF (bad file descriptor) exception. If handle_error() also calls close(), as asyncore's default implementation does, this will mean close() gets called twice on the same socket. I am attaching example code which demonstrates the problem on Linux 2.6.24 using python 2.5.2, 2.5.3rc1, and 2.6. In one window, run pollwritefail.py. In another window, establish a TCP connection to port 12345 and immediately close it without reading or writing. This can be done from within the python interactive interpreter like this: import socket s=socket.socket( socket.AF_INET, socket.SOCK_STREAM); s.connect( ('localhost', 12345)); s.close() The output from pollwritefail.py will look like this: writable() - asyncore asked if we have data to write handle_read() - asyncore asked us to read handle_close() - asyncore said the remote host closed connection close() - we are closing our end of the connection handle_write() - asyncore asked us to write handle_error() - asyncore exception: (9, 'Bad file descriptor') close() - we are closing our end of the connection IMHO, two things need fixing here: 1. When writable() returns True, the next handler asyncore calls should be handle_write(). Calling other handlers in between risks invalidating the writable() return value. 2. After close(), asyncore should not call handle_write(), even if writable() would return true. ---------- components: Library (Lib) files: pollwritefail.py messages: 78003 nosy: forest severity: normal status: open title: asyncore calls handle_write() on closed sockets when use_poll=True type: behavior versions: Python 2.5, Python 2.5.3, Python 2.6 Added file: http://bugs.python.org/file12390/pollwritefail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 02:34:15 2008 From: report at bugs.python.org (Eddie) Date: Thu, 18 Dec 2008 01:34:15 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229564055.62.0.444404801615.issue4621@psf.upfronthosting.co.za> Eddie added the comment: The error you got is caused by giving the wrong parameters. You gave a ZipInfo object instead of a filename. If you execute data = testzip.read(t1.filename) yo will have no problems. ---------- nosy: +Eddie _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 02:43:44 2008 From: report at bugs.python.org (Allan Crooks) Date: Thu, 18 Dec 2008 01:43:44 +0000 Subject: [issue4643] cgitb.html fails if getattr call raises exception In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> Message-ID: <1229564624.92.0.279833396059.issue4643@psf.upfronthosting.co.za> Allan Crooks added the comment: In terms of patching scanvars, I came up with the following solution: ORIGINAL: if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) SOLUTION: if parent is not __UNDEF__: try: value = getattr(parent, token, __UNDEF__) except Exception: value = __UNDEF__ vars.append((prefix + token, prefix, value)) I think this makes the most sense - it requires a small change, and it won't have any strange side effect. One slightly undesirable aspect is that for an attribute value which could not be determined (due to this problem), it will say that it was "undefined", which isn't entirely accurate. My initial patch changed value to be a string to be "could not determine value", but if the line of code looked like this: print 'B:', weird.b.upper() Then for something which shouldn't work, it would determine that the value of weird.b.upper is the string method - which isn't what we're after. So I would recommend my original patch (as described above) as the best solution. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 02:50:47 2008 From: report at bugs.python.org (osvenskan) Date: Thu, 18 Dec 2008 01:50:47 +0000 Subject: [issue3110] Multiprocessing package build problem on Solaris 10 In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za> Message-ID: <1229565047.91.0.506945532267.issue3110@psf.upfronthosting.co.za> osvenskan added the comment: I'm facing the same problem (getting a good definition of SEM_VALUE_MAX) for my posix_ipc extension. The patch presented here will get the compiler to shut up on OpenSolaris, but not for the reason you think. At least, that's the way I see it. On OpenSolaris (2008.05 is what I'm testing with), _SEM_VALUE_MAX is indeed #defined in sys/param.h, but it's inside this #ifdef on line 322: #if (defined(_KERNEL) || defined(_KMEMUSER)) Since multiprocessing.c doesn't #define either of these, both SEM_VALUE_MAX and _SEM_VALUE_MAX will remain undefined and so the patch will always fall back to INT_MAX. IMHO, given the choice between #defining _KERNEL or _KMEMUSER and calling sysconf(_SC_SEM_VALUE_MAX), I feel safer doing the latter. I did a survey of all the operating systems to which I have access (OpenSolaris 2008.05, OS X 10.5.5, RHEL?, Ubuntu 8.04, and FreeBSD 7). OpenSolaris is the only one that doesn't #define SEM_VALUE_MAX, and on all systems except for the possibly Red Hattish one, sysconf(_SC_SEM_VALUE_MAX) returned the same value as the definition of SEM_VALUE_MAX. I attached my code & results. Added file: http://bugs.python.org/file12391/explore_sem_value_max.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 02:51:35 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 18 Dec 2008 01:51:35 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks In-Reply-To: <1229536278.67.0.482183308094.issue1524639@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Wed, Dec 17, 2008 at 3:51 PM, Guilherme Polo wrote: > > Guilherme Polo added the comment: > > Rethinking about the changes done in Misc._configure I found out that > you don't need any of those there. > Isn't it the case of only improving the changes regarding callable > overwriting in Misc._options ? So if the value is a callable and the > option doesn't exist you also don't _register the callable. Maybe I'm > forgetting about something here, so you could bring an example that > fails on this reasoning. Uhm, this will fail in other places in Tkinter that are using _options for handling options not related to widget options but specific command options. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 02:53:10 2008 From: report at bugs.python.org (Roy Smith) Date: Thu, 18 Dec 2008 01:53:10 +0000 Subject: [issue4680] deque class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229565190.27.0.888284453834.issue4680@psf.upfronthosting.co.za> Roy Smith added the comment: And, FWIW, I did figure out a use case for clear(). I create a queue and pass it to two threads. One side or the other decides to abandon processing of the events currently in the queue. I can't just create a new queue, because you have no way to tell the other thread about it. You need to have clear() to do this. And, no, it should not clear the high water mark. As I see it, it comes down to this: If you bury this in the C code inside deque(), it's very efficient compared to the Python wrapper class. The downside is it makes the API larger than it would otherwise be, to satisfy a use case with limited demand. If you feel the efficiency gain doesn't justify the added complexity in the API, I'm OK with that. I just didn't want this shot down on the basis of, "He's asking us to invest the effort to write the code for something we don't see a need for", hence the offer to write it myself. But, it's your call if you want it or not. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 02:56:46 2008 From: report at bugs.python.org (Forest Wilkinson) Date: Thu, 18 Dec 2008 01:56:46 +0000 Subject: [issue2944] asyncore doesn't handle connection refused correctly In-Reply-To: <1211462641.02.0.497686644895.issue2944@psf.upfronthosting.co.za> Message-ID: <1229565406.01.0.408328934493.issue2944@psf.upfronthosting.co.za> Changes by Forest Wilkinson : ---------- nosy: +forest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 03:04:41 2008 From: report at bugs.python.org (Tim Peters) Date: Thu, 18 Dec 2008 02:04:41 +0000 Subject: [issue4680] deque class should include high-water mark In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za> Message-ID: <1229565881.07.0.736826771652.issue4680@psf.upfronthosting.co.za> Tim Peters added the comment: There's no need to keep asking -- this report was already rejected ;-) Seriously, the efficiency argument carries no weight with me -- in 15 years of using Queue in a variety of applications, the time it takes to .put and .get "here's a piece of work to do" descriptors is trivial compared to the cost of /doing/ the "piece of work". A Python-coded subclass would have been plenty fast enough in any of those apps (assuming I ever wanted to track a highwater mark, which to date I never have). ---------- nosy: +tim_one _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 03:37:55 2008 From: report at bugs.python.org (Brandon Dixon) Date: Thu, 18 Dec 2008 02:37:55 +0000 Subject: [issue4691] IDLE Code Caching Windows In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za> Message-ID: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za> New submission from Brandon Dixon : I made changes to my code and hit F5 to run it through IDLE. The code appeared to run without any errors, but when I closed everything out and ran it again it turned out to be full of errors. I am able to replicate this problem with my code and have seen others have the same problem, but its unclear when and what causes the caching to take place. I created a test file that only contained "print hello". I ran this, made changes and then ran it again. The changes were reflected, but after testing my code, it still cached. Attached is a simple python file I used to test everything out. Run the test, then comment out the Struct class and run it again. No errors should appear, but if you close the code, reopen it and then run it again it will error. ---------- components: IDLE files: bug-test.py messages: 78010 nosy: brandon.dixon severity: normal status: open title: IDLE Code Caching Windows type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file12392/bug-test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 07:12:58 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 18 Dec 2008 06:12:58 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229580778.51.0.608543050511.issue4688@psf.upfronthosting.co.za> Martin v. L?wis added the comment: IIUC, you try to find various places where tuples are created, and check whether they create tuples that don't need tracking. I think this approach is difficult to maintain, and also may miss some objects. I'd rather see that integrated into collection: e.g. when iterating over survivors of a collection, check whether they can be untracked. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 07:25:22 2008 From: report at bugs.python.org (Daniel Stutzbach) Date: Thu, 18 Dec 2008 06:25:22 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229581522.0.0.322346179887.issue4688@psf.upfronthosting.co.za> Daniel Stutzbach added the comment: Unfortunately, the check is O(n), so it can get a little expensive. I suppose that's no worse than traversing the tuple to look for a cycle, though. Perhaps it could be done at the same time? Can _PyObject_GC_UNTRACK() be safely called from tp_traverse? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 07:43:47 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 18 Dec 2008 06:43:47 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229581522.0.0.322346179887.issue4688@psf.upfronthosting.co.za> Message-ID: <4949F11F.6000701@v.loewis.de> Martin v. L?wis added the comment: > Unfortunately, the check is O(n), so it can get a little expensive. Not in the typical case, I guess. *If* you have to go through all objects, then likely you end up untracking the object. If you can't untrack, you typically find a tracked object in the content quickly. > I suppose that's no worse than traversing the tuple to look for a cycle, > though. Correct. Collection is O(n) per object, anyway. > Perhaps it could be done at the same time? > Can _PyObject_GC_UNTRACK() be safely called from tp_traverse? No. However, I doubt that iterating over the object twice is significantly slower than iterating over it once and performing both checks. Plus, the check for tracked elements can return as soon as one such object is found. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 08:25:39 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 18 Dec 2008 07:25:39 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229585139.49.0.924639495079.issue4688@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 08:33:04 2008 From: report at bugs.python.org (Francesco Ricciardi) Date: Thu, 18 Dec 2008 07:33:04 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229585584.27.0.921830190199.issue4621@psf.upfronthosting.co.za> Francesco Ricciardi added the comment: If that is what is requested, then the manual entry for ZipFile.read must be corrected, because it states: "ZipFile.read(name[, pwd]) .... name is the name of the file in the archive, or a ZipInfo object." However, Eddie, you haven't tried what you suggested, because this is what you would get: >>> import zipfile >>> testzip = zipfile.ZipFile('test.zip') >>> t1 = testzip.infolist()[0] >>> t1.filename 't?st.xml' >>> data = testzip.read(t1.filename) Traceback (most recent call last): File "", line 1, in File "C:\Python30\lib\zipfile.py", line 843, in read return self.open(name, "r", pwd).read() File "C:\Python30\lib\zipfile.py", line 883, in open % (zinfo.orig_filename, fname)) zipfile.BadZipfile: File name in directory 't?st.xml' and header b't\x82st.xml' differ. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 09:38:21 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 18 Dec 2008 08:38:21 +0000 Subject: [issue4615] de-duping function in itertools In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za> Message-ID: <1229589501.39.0.58372422351.issue4615@psf.upfronthosting.co.za> Raymond Hettinger added the comment: My inclination is to not include this as a basic C coded itertool because it holds potentially all of the data in memory (generally, not a characteristic of an itertool) and because I don't see it as a basic building block (itertools are intended to be elemental, composable components of an iterator algebra). Also, the pure python equivalent of dedup() is both easy to write and runs efficiently (it gains little from being recoded in C). Instead, I'm think of adding two recipes to the itertools docs: def unique_everseen(iterable, key=None): # unique_everseen('AAAABBBCCDAABBB') --> A B C D # unique_everseen('ABBCcAD', str.lower) --> A B C D seen = set() seen_add = seen.add if key is None: for elem in iterable: if elem not in seen: seen_add(elem) yield elem else: for elem in iterable: k = key(elem) if k not in seen: seen_add(k) yield elem def unique_lastseen(iterable, key=None): # unique_lastseen('AAAABBBCCDAABBB') --> A B C D A B # unique_lastseen('ABBCcAD', str.lower) --> A B C A D return imap(next, imap(itemgetter(1), groupby(iterable, key))) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 09:49:52 2008 From: report at bugs.python.org (Ned Deily) Date: Thu, 18 Dec 2008 08:49:52 +0000 Subject: [issue4692] Framework build fails if OS X on case-sensitive file system In-Reply-To: <1229590192.68.0.523671784662.issue4692@psf.upfronthosting.co.za> Message-ID: <1229590192.68.0.523671784662.issue4692@psf.upfronthosting.co.za> New submission from Ned Deily : In the main python Makefile.pre.in, the frameworkinstallextras target, only used on OS X, has a bogus "Make" command instead of "$(MAKE)" as in other targets. Traditionally and by default, the OS X root file system is case-insensitive, in which case "Make" coincidentally does invoke /usr/bin/make. However, with OS X installed on a case-sensitive fs, the command fails. One-liner patch attached. ---------- components: Build files: makefile-make.diff keywords: patch messages: 78016 nosy: nad severity: normal status: open title: Framework build fails if OS X on case-sensitive file system versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file12393/makefile-make.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 10:28:49 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 09:28:49 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229580778.51.0.608543050511.issue4688@psf.upfronthosting.co.za> Message-ID: <1229592517.9355.7.camel@localhost> Antoine Pitrou added the comment: Le jeudi 18 d?cembre 2008 ? 06:12 +0000, Martin v. L?wis a ?crit : > I think this approach is difficult to maintain, and also may miss some > objects. But what counts is where tuples can be created in massive numbers or sizes: the eval loop, the tuple type's tp_new, and a couple of other places. We don't need to optimize every single tuple created by the interpreter or extension modules (and even the, one can simply call _PyTuple_Optimize()). > I'd rather see that integrated into collection: e.g. when iterating over > survivors of a collection, check whether they can be untracked. That's what I had tried at first, but it crashes. I haven't investigated, but I suspect removing an object from the GC list while that list is being walked isn't very well supported by the GC. Also, this approach is more expensive since it involves checking tuples again and again each time they are walked by the GC. The patch only does it once, when the tuple is being built. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 10:36:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 09:36:32 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229592517.9355.7.camel@localhost> Message-ID: <1229592985.9355.10.camel@localhost> Antoine Pitrou added the comment: > > I'd rather see that integrated into collection: e.g. when iterating over > > survivors of a collection, check whether they can be untracked. > > That's what I had tried at first, but it crashes. To be clearer, I tried adding it to the tp_traverse method of tuples. I could try to add it to the collection machinery in gcmodule.c instead. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:11:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 18 Dec 2008 10:11:16 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229595076.88.0.594235766862.issue2183@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Recommend having both MAP_ADD and STORE_MAP. The latter is repeated often in a typical dict literal so it needs to be compact and fast. The former needs the flexibility of the offset argument to be workable in a dict comprehension. I also like that MAP_ADD eliminates the need for the awkward ROT_TWO stack re-arrangement. Also, MAP_ADD can include a PREDICT(JUMP_ABSOLUTE) for a further speed-up. All in all, this is a nice clean-up and speed-up that more than justifies a second opcode. ---------- assignee: rhettinger -> pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:34:08 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 18 Dec 2008 10:34:08 +0000 Subject: [issue4691] IDLE Code Caching Windows In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za> Message-ID: <1229596448.6.0.251857061903.issue4691@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: You are using IDLE with the "-n" option, so the same interpreter session is reused each time you hit F5. The second run works because the Struct from the first run is still present - but disappears of course when you restart IDLE. It's not really caching, but normal manipulation of variables, just like "a = 5" followed by "print a" works because 'a' is saved in-between. I suggest to remove this "-n" option, a fresh interpreter is started each time you press F5, and errors appear sooner... ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:37:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 10:37:07 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229596626.88.0.504410760348.issue4688@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an alternate patch which does the tuple optimization in the GC. I don't like it a lot, first because it puts some type-specific code in gcmodule, second because it invalidates the dict optimization (since tuples are untracked only when walked by the GC, they are still tracked when added to a dict and therefore the dict will be tracked too). Added file: http://bugs.python.org/file12394/dictopts2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:37:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 10:37:32 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229596652.59.0.731322086307.issue4688@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12394/dictopts2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:37:41 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 10:37:41 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229596661.23.0.83912223645.issue4688@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file12395/tupleopts-alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:38:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 10:38:15 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229596695.04.0.325541018984.issue4688@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12395/tupleopts-alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:38:23 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 10:38:23 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229596703.73.0.258246711505.issue4688@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file12396/tupleopts-alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:45:10 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 18 Dec 2008 10:45:10 +0000 Subject: [issue4685] IDLE will not open (2.6.1 on WinXP pro) In-Reply-To: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za> Message-ID: <1229597110.36.0.109729784052.issue4685@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Can you start it from a command prompt (cmd.exe): > cd c:\python26 > python Lib\idlelib\idle.py The console may display interesting error messages. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 12:09:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 11:09:18 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1229598558.32.0.708439618373.issue2183@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed to py3k in r67839. ---------- resolution: accepted -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 13:04:16 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 12:04:16 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1229601856.2.0.346226815378.issue4688@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch which combines the alternate approach (untrack simple objects when doing a GC collection) for tuples and dicts. I'm surprised by the results: after a full regression test suite, there are roughly 55000 tracked objects (measured with len(gc.get_objects())) while there are 150000 of them with the original interpreter. Some eyes are welcome. Added file: http://bugs.python.org/file12397/tuple+dictopts-alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:17:54 2008 From: report at bugs.python.org (Eddie) Date: Thu, 18 Dec 2008 14:17:54 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229609874.94.0.568250415039.issue4621@psf.upfronthosting.co.za> Eddie added the comment: Sorry, my bad. I did tried it but with the wrong version (2.5). And it worked perfectly. So sorry again for my mistake. Anyways, I've found the error. The problem is caused by different encodings used when zipping. In open, the method is comparing b't\x82st.xml' against b't\xc3\xa9st.xml', and of course they are different. But they are no so different, because b't\x82st.xml' is 't?st'.encode('cp437') and b't\xc3\xa9st.xml' is 't?st'.encode(utf-8). The problem arises because the open method supposes the filename is in utf-8 encoding, but in __init__ it realizes that the encoding depends on the flags. if flags & 0x800: filename = filename.decode.('utf-8') else: filename = filename.decode.('cp437') _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:31:54 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 18 Dec 2008 14:31:54 +0000 Subject: [issue4690] asyncore calls handle_write() on closed sockets when use_poll=True In-Reply-To: <1229560322.27.0.660252722227.issue4690@psf.upfronthosting.co.za> Message-ID: <1229610714.5.0.305969448676.issue4690@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola, josiah.carlson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:39:18 2008 From: report at bugs.python.org (Daniel Diniz) Date: Thu, 18 Dec 2008 14:39:18 +0000 Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname? In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za> Message-ID: <1229611158.18.0.159731471379.issue4683@psf.upfronthosting.co.za> Daniel Diniz added the comment: Chris, Is there a chance that this is some sort of protection on LJ's side? Does a given instance mean the same connection being reused? What happens with longer sleeps? ---------- nosy: +ajaksu2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:40:22 2008 From: report at bugs.python.org (Senthil) Date: Thu, 18 Dec 2008 14:40:22 +0000 Subject: [issue4217] Add file comparisons to the unittest library In-Reply-To: <1225153586.34.0.218245937188.issue4217@psf.upfronthosting.co.za> Message-ID: <1229611222.57.0.0623889796938.issue4217@psf.upfronthosting.co.za> Changes by Senthil : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:49:25 2008 From: report at bugs.python.org (Chris Boyle) Date: Thu, 18 Dec 2008 14:49:25 +0000 Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname? In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za> Message-ID: <1229611765.62.0.382727449767.issue4683@psf.upfronthosting.co.za> Chris Boyle added the comment: When I say a given instance, I mean an HTTPDigestAuthHandler object. If I take the three lines before my loop (authhandler=, opener=, install_opener) and move them into the loop, the problem goes away, whereas moving only the latter two of those doesn't help. So, creating a new HTTPDigestAuthHandler each time fixes the problem, where surely it shouldn't make any difference? Also, I've tried sleeps of 30 seconds, with the same results (reuse handler -> fail on the 3rd request, new handler each time -> works for all requests). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:15:00 2008 From: report at bugs.python.org (Daniel Diniz) Date: Thu, 18 Dec 2008 15:15:00 +0000 Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname? In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za> Message-ID: <1229613300.88.0.641144348324.issue4683@psf.upfronthosting.co.za> Daniel Diniz added the comment: Hmm, notice that AbstractDigestAuthHandler handles retries: class AbstractDigestAuthHandler: def __init__(self, passwd=None): ... self.retried = 0 ... def reset_retry_count(self): self.retried = 0 def http_error_auth_reqed(self, auth_header, host, req, headers): authreq = headers.get(auth_header, None) if self.retried > 5: # Don't fail endlessly - if we failed once, we'll probably # fail a second time. Hm. Unless the Password Manager is # prompting for the information. Crap. This isn't great # but it's better than the current 'repeat until recursion # depth exceeded' approach raise HTTPError(req.get_full_url(), 401, "digest auth failed", headers, None) else: self.retried += 1 if authreq: scheme = authreq.split()[0] if scheme.lower() == 'digest': return self.retry_http_digest_auth(req, authreq) The fact that your password manager is queried six times suggests you're seeing the "if self.retried > 5:" above. Could you make a local copy of /usr/lib/python2.5/urllib2.py and add some prints (specially around get_authorization) to see what is going on? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:44:01 2008 From: report at bugs.python.org (David W. Lambert) Date: Thu, 18 Dec 2008 15:44:01 +0000 Subject: [issue4615] de-duping function in itertools In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za> Message-ID: <1229615041.46.0.826492236421.issue4615@psf.upfronthosting.co.za> David W. Lambert added the comment: (but of course with imap in version 2.7 and with something else in version 3.x) ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:52:39 2008 From: report at bugs.python.org (Senthil) Date: Thu, 18 Dec 2008 15:52:39 +0000 Subject: [issue4693] Idle for Python 3.0 is default even without doing make fullinstall In-Reply-To: <1229615559.55.0.416085071755.issue4693@psf.upfronthosting.co.za> Message-ID: <1229615559.55.0.416085071755.issue4693@psf.upfronthosting.co.za> New submission from Senthil : I am not sure, if this is intentional. But if you look at Python 3k and 3.1 installation. changing mode of /usr/local/bin/pydoc to 755 changing mode of /usr/local/bin/idle to 755 changing mode of /usr/local/bin/2to3 to 755 changing mode of /usr/local/bin/smtpd.py to 755 running install_egg_info * Note: not installed as 'python'. * Use 'make fullinstall' to install as 'python'. * However, 'make fullinstall' is discouraged, * as it will clobber your Python 2.x installation. ors at goofy:~/python/py3k$ pydoc, idle, 2to3 and smtp.py by default are Py3k's. Where as python is Py2.x's. Do you see the difference when one wants to try out python prompt. - If he types python in the console, he would be greeted by 2.x - If he types idle, he would be greeted by 3k. pydoc may cause similar confusion too. 2to3 is okay because it is to be used by 3k, Not sure about smtp.py Do you agree this as an issue and if so, how do we address it? - label idle as idle3.0 and pydoc as pydoc3.0 and make it default with make fullinstall ? ---------- components: IDLE messages: 78030 nosy: orsenthil severity: normal status: open title: Idle for Python 3.0 is default even without doing make fullinstall type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 17:31:43 2008 From: report at bugs.python.org (Ilan) Date: Thu, 18 Dec 2008 16:31:43 +0000 Subject: [issue4685] IDLE will not open (2.6.1 on WinXP pro) In-Reply-To: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za> Message-ID: <1229617903.45.0.929206941242.issue4685@psf.upfronthosting.co.za> Ilan added the comment: It didn't work. "cd c:\python26" successfully prompted "C:\Python26>", But then entering "python Lib\idlelib\idle.py" did not work, the message is too long to enter in this reply but here are some of the lines in the body: "Unhandled server exception! Thread: SockThread" [...] "ImportError: cannot import name Random *** Unrecoverable, server existing!" [...] "EOFError" I hope this helps, I have no clue what to do... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:11:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 17:11:12 +0000 Subject: [issue4583] segfault when mutating memoryview to array.array when array is resized In-Reply-To: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za> Message-ID: <1229620272.9.0.48361100786.issue4583@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed in r67840. No need to backport to 2.x since the array object there doesn't support the new buffer protocol. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:21:23 2008 From: report at bugs.python.org (Matteo Bertini) Date: Thu, 18 Dec 2008 17:21:23 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1229620883.92.0.622640330921.issue1068268@psf.upfronthosting.co.za> Matteo Bertini added the comment: Python 2.5.3 is near but the I think the fix in http://svn.python.org/view?rev=65475&view=rev is not enough, there are a lot of other places where EINTR can cause and error. ---------- versions: +Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:29:20 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Dec 2008 17:29:20 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1229621360.39.0.726928777318.issue1068268@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:40:24 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 18 Dec 2008 17:40:24 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1229622024.38.0.169460796479.issue4017@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I've uploaded a .dmg for 2.6.1 to http://www.python.org/ftp/python/2.6.1/. Could you please test it? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:53:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 17:53:15 +0000 Subject: [issue3860] GzipFile and BZ2File should support context manager protocol In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za> Message-ID: <1229622795.35.0.913057699394.issue3860@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch for the trunk. I'm waiting for the opinion other developers before deciding to commit or no. ---------- keywords: +patch nosy: +pitrou stage: -> patch review Added file: http://bugs.python.org/file12398/withgzip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:09:00 2008 From: report at bugs.python.org (Joachim Strombergson) Date: Thu, 18 Dec 2008 18:09:00 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1229623740.01.0.981344046179.issue4017@psf.upfronthosting.co.za> Joachim Strombergson added the comment: I downloaded the newly built 2.6.1 dmg and can confirm that, at least for me: (1) import Tkinter works. (2) Starting IDLE works. It looks like we have a winner, good job Benjamin! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:43:16 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 18 Dec 2008 18:43:16 +0000 Subject: [issue3860] GzipFile and BZ2File should support context manager protocol In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za> Message-ID: <1229625796.66.0.891033595977.issue3860@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's the StringIO discussion: #1286 ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 20:09:58 2008 From: report at bugs.python.org (David M. Beazley) Date: Thu, 18 Dec 2008 19:09:58 +0000 Subject: [issue4694] _call_method() in multiprocessing documentation In-Reply-To: <1229627398.43.0.465661733522.issue4694@psf.upfronthosting.co.za> Message-ID: <1229627398.43.0.465661733522.issue4694@psf.upfronthosting.co.za> New submission from David M. Beazley : The documentation for "Proxy Objects" in the multiprocessing module describes a method "_call_method" and gives various examples. The only problem is that the method is actually called "_callmethod" (i.e., no underscore between "call" and "method"). ---------- assignee: georg.brandl components: Documentation messages: 78038 nosy: beazley, georg.brandl severity: normal status: open title: _call_method() in multiprocessing documentation type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 20:43:54 2008 From: report at bugs.python.org (David M. Beazley) Date: Thu, 18 Dec 2008 19:43:54 +0000 Subject: [issue4694] _call_method() in multiprocessing documentation In-Reply-To: <1229627398.43.0.465661733522.issue4694@psf.upfronthosting.co.za> Message-ID: <1229629434.48.0.120128862099.issue4694@psf.upfronthosting.co.za> David M. Beazley added the comment: The _get_value() method is also in error. It's called "_getvalue()" in the source code. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 20:53:32 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 18 Dec 2008 19:53:32 +0000 Subject: [issue4692] Framework build fails if OS X on case-sensitive file system In-Reply-To: <1229590192.68.0.523671784662.issue4692@psf.upfronthosting.co.za> Message-ID: <1229630012.79.0.307254443892.issue4692@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed in r67844 (trunk), r67845 (2.6), r67846 (py3k) and r67847 (3.0). Thanks for the report and patch! ---------- nosy: +marketdickinson resolution: -> fixed status: open -> closed versions: +Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:53:29 2008 From: report at bugs.python.org (David M. Beazley) Date: Thu, 18 Dec 2008 20:53:29 +0000 Subject: [issue4695] Bad AF_PIPE address in multiprocessing documentation In-Reply-To: <1229633609.42.0.990434424084.issue4695@psf.upfronthosting.co.za> Message-ID: <1229633609.42.0.990434424084.issue4695@psf.upfronthosting.co.za> New submission from David M. Beazley : In the "Address Formats" part of the "Listeners and Clients" section of the documentation for the multiprocessing module, AF_PIPE addresses are described as having this format: r'\\\\ServerName\\pipe\\PipeName' However, it is really this: r'\\ServerName\pipe\PipeName' Be careful with raw strings. The documentation is showing the output of repr(), not a properly formed raw string. I verified this fix on Windows XP. ---------- assignee: georg.brandl components: Documentation messages: 78041 nosy: beazley, georg.brandl severity: normal status: open title: Bad AF_PIPE address in multiprocessing documentation versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:59:28 2008 From: report at bugs.python.org (Ben Artin) Date: Thu, 18 Dec 2008 20:59:28 +0000 Subject: [issue4696] email module does not fold headers In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za> Message-ID: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za> New submission from Ben Artin : RFC 2822 allows for certain headers to be spread across multiple lines (section 2.2.3). In particular, subject, comments, and keywords headers behave this way (section 3.6.5). I think the email module should unfold such headers. See attached patch. ---------- components: Library (Lib) files: feedparser.diff keywords: patch messages: 78042 nosy: bromine severity: normal status: open title: email module does not fold headers type: behavior versions: Python 2.5.3, Python 2.6 Added file: http://bugs.python.org/file12399/feedparser.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 22:55:59 2008 From: report at bugs.python.org (Dan) Date: Thu, 18 Dec 2008 21:55:59 +0000 Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname? In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za> Message-ID: <1229637359.8.0.102180240578.issue4683@psf.upfronthosting.co.za> Dan added the comment: Reasonable idea, Daniel, but changing self.retried makes no difference. What does solve Chris' problem (which I can reproduce, btw) is preventing the nonce_count from incrementing. i.e. comment out the line : self.nonce_count += 1 in AbstractDigestAuthHandler.get_authorization This makes me wonder if all this is being caused by LJ, intentionally or not, rejecting repeated requests. ---------- nosy: +danohuiginn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 23:38:46 2008 From: report at bugs.python.org (Erik Sternerson) Date: Thu, 18 Dec 2008 22:38:46 +0000 Subject: [issue4697] Clarification needed for subprocess convenience functions in Python 3.0 documentation In-Reply-To: <1229639926.42.0.148346295648.issue4697@psf.upfronthosting.co.za> Message-ID: <1229639926.42.0.148346295648.issue4697@psf.upfronthosting.co.za> New submission from Erik Sternerson : There are two new convenience functions in the subprocess module since Python 3.0, getstatusoutput and getoutput. These are UNIX ONLY functions (as per note "# NB This only works (and is only relevant) for UNIX." in subprocess.py) I believe the documentation page http://docs.python.org/3.0/library/subprocess.html does not reflect this sufficiently (not sure it does at all). I suggest a note should be added saying "Availability: UNIX" to the two functions mentioned. ---------- assignee: georg.brandl components: Documentation messages: 78044 nosy: Erik Sternerson, georg.brandl severity: normal status: open title: Clarification needed for subprocess convenience functions in Python 3.0 documentation versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 23:58:58 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 22:58:58 +0000 Subject: [issue4698] Solaris buildbot failure on trunk in test_hostshot In-Reply-To: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za> Message-ID: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The Solaris buildbot seems to fail deterministically on trunk with the following message. ====================================================================== FAIL: test_logreader_eof_error (test.test_hotshot.HotShotTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/test/test_hotshot.py", line 130, in test_logreader_eof_error self.assertRaises((IOError, EOFError), _hotshot.logreader, ".") AssertionError: (, ) not raised ---------------------------------------------------------------------- (see e.g. http://www.python.org/dev/buildbot/trunk.stable/sparc%20solaris10%20gcc%20trunk/builds/61/step-test/0 ) ---------- components: Extension Modules messages: 78045 nosy: amaury.forgeotdarc, pitrou priority: normal severity: normal status: open title: Solaris buildbot failure on trunk in test_hostshot type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:01:43 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 23:01:43 +0000 Subject: [issue3860] GzipFile and BZ2File should support context manager protocol In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za> Message-ID: <1229641303.09.0.679359869439.issue3860@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks. The outcome of the StringIO discussion isn't clearly negative, although Guido does not see a big benefit in it. If some people are opposed to this, please stand up :) Otherwise I'll commit the patch to trunk. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:02:36 2008 From: report at bugs.python.org (Dan) Date: Thu, 18 Dec 2008 23:02:36 +0000 Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname? In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za> Message-ID: <1229641356.04.0.11627373479.issue4683@psf.upfronthosting.co.za> Dan added the comment: Actually, this does look more like an urllib2 bug. According to RFC 2617, the nonce count should represent the number of requests sent with a particular nonce. But we don't reset the nonce count when we start using a new nonce. That discrepancy in nonce counts causes LJ to reject the connection. Why does it fail the third time, rather than the second? See the LJ code from http://code.sixapart.com/svn/livejournal/trunk/cgi-bin/ljlib.pl (which I *think* applies here, but could easily be wrong): # check the nonce count # be lenient, allowing for error of magnitude 1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:17:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 18 Dec 2008 23:17:20 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229592517.9355.7.camel@localhost> Message-ID: <494AD9FD.6000205@v.loewis.de> Martin v. L?wis added the comment: > But what counts is where tuples can be created in massive numbers or > sizes: the eval loop, the tuple type's tp_new, and a couple of other > places. We don't need to optimize every single tuple created by the > interpreter or extension modules (and even the, one can simply call > _PyTuple_Optimize()). Still, I think this patch does too much code duplication. There should be only a single function that does the optional untracking; this then gets called from multiple places. > Also, this approach is more expensive I'm skeptical. It could well be *less* expensive, namely if many tuples get deleted before gc even happens. Then you currently check whether you can untrack them, which is pointless if the tuple gets deallocated quickly, anyway. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:43:58 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2008 23:43:58 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <494AD9FD.6000205@v.loewis.de> Message-ID: <1229643833.27526.5.camel@localhost> Antoine Pitrou added the comment: Hello again, > Still, I think this patch does too much code duplication. There should > be only a single function that does the optional untracking; this then > gets called from multiple places. The point was to avoid slowing down the critical path of tuple creation in the most common cases. If it is considered too hackish, then I agree the other patch (tuple+dictopts-alt.patch) should be considered instead. By the way, perhaps pybench should grow a GC test (e.g. derived from Greg's script). What do you think? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:28:47 2008 From: report at bugs.python.org (Kurt Mueller) Date: Fri, 19 Dec 2008 00:28:47 +0000 Subject: [issue4699] Typo in documentation of "signal" In-Reply-To: <1229646526.98.0.647202110471.issue4699@psf.upfronthosting.co.za> Message-ID: <1229646526.98.0.647202110471.issue4699@psf.upfronthosting.co.za> New submission from Kurt Mueller : in documentation of "signal" http://docs.python.org/library/signal.html --------------------------------- signal.SIG_DFL This is one of two standard signal handling options; it will simply perform the default function for the signal. For example, on most systems the default action for SIGQUIT is to dump core and exit, while the default action for SIGCLD is to simply ignore it. --------------------------------- Typo: SIGCLD should be SIGCHLD ---------- assignee: georg.brandl components: Documentation messages: 78050 nosy: georg.brandl, yam850 severity: normal status: open title: Typo in documentation of "signal" versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 02:19:19 2008 From: report at bugs.python.org (Don Braffitt) Date: Fri, 19 Dec 2008 01:19:19 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1229649559.1.0.0856494325525.issue4017@psf.upfronthosting.co.za> Don Braffitt added the comment: >I've uploaded a .dmg for 2.6.1 to >http://www.python.org/ftp/python/2.6.1/. Could you please test it? I installed the 2.6.1 .dmg on Mac OS X 10.5.5, and IDLE once again works fine. - Don _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 03:29:24 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 19 Dec 2008 02:29:24 +0000 Subject: [issue4699] Typo in documentation of "signal" In-Reply-To: <1229646526.98.0.647202110471.issue4699@psf.upfronthosting.co.za> Message-ID: <1229653764.2.0.940243533716.issue4699@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67848. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 03:32:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 19 Dec 2008 02:32:11 +0000 Subject: [issue4694] _call_method() in multiprocessing documentation In-Reply-To: <1229627398.43.0.465661733522.issue4694@psf.upfronthosting.co.za> Message-ID: <1229653931.72.0.35885093245.issue4694@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67849. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 07:34:23 2008 From: report at bugs.python.org (Johnny Lee) Date: Fri, 19 Dec 2008 06:34:23 +0000 Subject: [issue4653] Patch to fix typos for Py3K In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1229668463.92.0.119904086431.issue4653@psf.upfronthosting.co.za> Johnny Lee added the comment: > It's difficult to really test such errors. When I can't control the called function, I usually step through the code in a debugger and change the result variable in question to the appropriate value to see if the code handles failed function calls correctly. In the three Win32 API cases, it's clear that the failure path was not tested. And I can't see how the ferr if statement was tested with a failure value either. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 09:31:33 2008 From: report at bugs.python.org (saa) Date: Fri, 19 Dec 2008 08:31:33 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t, and size calculation needs corrected In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229675493.61.0.0182548074843.issue4681@psf.upfronthosting.co.za> saa added the comment: There are bigger problems here. When the code calculates the size to map if size is passed as zero, it simply assigns the 64-bit st_size to the size to mmap. On a 32-bit system, it is obvious that the amount to map must be less than a 32-bit value. The calculation should take into account at least the following two things: 1) it should be the size of the file minus the offset, and 2) it shouldn't ask for an unreasonable amount of memory. I will experiment with this and submit a new patch (and delete the two I've already uploaded) within a couple of days, or at a minimum, provide an update to this bug. ---------- title: mmap offset should be off_t instead of ssize_t -> mmap offset should be off_t instead of ssize_t, and size calculation needs corrected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 10:13:05 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 19 Dec 2008 09:13:05 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229677985.98.0.394711837241.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Posted some doc cleanups in r67850 and r67851. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 15:02:58 2008 From: report at bugs.python.org (Michael Newman) Date: Fri, 19 Dec 2008 14:02:58 +0000 Subject: [issue4700] UnicodeEncodeError in license() In-Reply-To: <1229695377.92.0.283252964169.issue4700@psf.upfronthosting.co.za> Message-ID: <1229695377.92.0.283252964169.issue4700@psf.upfronthosting.co.za> New submission from Michael Newman : UnicodeEncodeError occurs for Microsoft portion of "license()". Confirmed on 3 separate Windows XP computers: Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> license() A. HISTORY OF THE SOFTWARE ========================== Python was created in the early 1990s by Guido van Rossum at Stichting Mathematisch Centrum (CWI, see http://www.cwi.nl) in the Netherlands as a successor of a language called ABC. Guido remains Python's ... skipping to end ... distribution specified by Microsoft. In particular, you must require distributors and external end users to agree to terms that protect the Microsoft Distributable Code at least as much as Microsoft's own requirements for the Distributable Code. See Microsoft's documentation (included in its developer tools and on its website at microsoft.com) for specific details. Redistribution of the Windows binary build of the Python interpreter complies with this agreement, provided that you do not: - alter any copyright, trademark or patent notice in Microsoft's Hit Return for more, or q (and Return) to quit: Distributable Code; Traceback (most recent call last): File "", line 1, in File "C:\Python30\lib\site.py", line 385, in __call__ print(self.__lines[i]) File "C:\Python30\lib\io.py", line 1491, in write b = encoder.encode(s) File "C:\Python30\lib\encodings\cp437.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_map)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\u2019' in position 15: character maps to ---------- components: Windows messages: 78057 nosy: mnewman severity: normal status: open title: UnicodeEncodeError in license() type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 15:53:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 19 Dec 2008 14:53:52 +0000 Subject: [issue4567] Registry key not set if unattended installation used In-Reply-To: <1228587246.7.0.370739440379.issue4567@psf.upfronthosting.co.za> Message-ID: <1229698432.27.0.777098842832.issue4567@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is not a bug. The registry keys do get set, though not in HKEY_LOCAL_MACHINE, but in HKEY_CURRENT_USER. To install quietly for all users, you need to add ALLUSERS=1; see http://www.python.org/download/releases/2.5/msi/ ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 16:21:11 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 15:21:11 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : As reported by Dmitry Vasiliev on python-dev, a range object suddenly becomes hash()able after an attribute access, e.g. by dir(). If I understand correctly, then the reason is that PyRange_Type doesn't set tp_hash and PyType_Ready is not normally called on the type, but only e.g. in PyObject_GenericGetAttr. I don't see any use for range objects being hashable, as they don't even have meaningful equality defined on them. So I'd recommend making them unhashable. The attached patch does this and adds a test. ---------- components: Interpreter Core messages: 78059 nosy: hagen severity: normal status: open title: range objects becomes hashable after attribute access type: behavior versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 16:22:16 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 15:22:16 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229700136.4.0.135483707194.issue4701@psf.upfronthosting.co.za> Changes by Hagen F?rstenau : ---------- keywords: +patch Added file: http://bugs.python.org/file12400/rangehash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 16:51:17 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 19 Dec 2008 15:51:17 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229701877.81.0.387905723651.issue4701@psf.upfronthosting.co.za> Guilherme Polo added the comment: You don't need to cast PyObject_HashNotImplemented to hashfunc ---------- nosy: +gpolo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:02:24 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 16:02:24 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229702544.43.0.288990042096.issue4701@psf.upfronthosting.co.za> Hagen F?rstenau added the comment: Why does every other place seem to do the cast? Historical reasons? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:09:49 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 19 Dec 2008 16:09:49 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229702544.43.0.288990042096.issue4701@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Fri, Dec 19, 2008 at 2:02 PM, Hagen F?rstenau wrote: > > Hagen F?rstenau added the comment: > > Why does every other place seem to do the cast? Historical reasons? > No, if you look at the functions being casted you will notice them do not take a pointer to PyObject as the first argument, if you are talking about tp_hash specifically. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:14:15 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 16:14:15 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229703255.71.0.93799267647.issue4701@psf.upfronthosting.co.za> Hagen F?rstenau added the comment: I'm talking about places like these: [hagenf at chage py3k]$ grep -R "(hashfunc)PyObject_HashNotImplemented" Objects/*.c Modules/*.c Objects/dictobject.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ Objects/listobject.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ Objects/setobject.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ Modules/_collectionsmodule.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:27:21 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 19 Dec 2008 16:27:21 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229703255.71.0.93799267647.issue4701@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Fri, Dec 19, 2008 at 2:14 PM, Hagen F?rstenau wrote: > > Hagen F?rstenau added the comment: > > I'm talking about places like these: > > [hagenf at chage py3k]$ grep -R "(hashfunc)PyObject_HashNotImplemented" > Objects/*.c Modules/*.c > Objects/dictobject.c: (hashfunc)PyObject_HashNotImplemented, /* > tp_hash */ > Objects/listobject.c: (hashfunc)PyObject_HashNotImplemented, /* > tp_hash */ > Objects/setobject.c: (hashfunc)PyObject_HashNotImplemented, /* > tp_hash */ > Modules/_collectionsmodule.c: (hashfunc)PyObject_HashNotImplemented, > /* tp_hash */ I have checked some of the examples you gave and noticed they were re-added (or changed) recently, but all these casts could be removed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:50:09 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 16:50:09 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229705409.8.0.207816246391.issue4701@psf.upfronthosting.co.za> Hagen F?rstenau added the comment: Here's an updated patch without the cast and a separate patch for removing the other casts. Added file: http://bugs.python.org/file12401/rangehash2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:50:36 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 16:50:36 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229705436.08.0.784584038007.issue4701@psf.upfronthosting.co.za> Changes by Hagen F?rstenau : Added file: http://bugs.python.org/file12402/remove_casts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:50:40 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 16:50:40 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229705440.77.0.519218287008.issue4701@psf.upfronthosting.co.za> Changes by Hagen F?rstenau : Removed file: http://bugs.python.org/file12400/rangehash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:57:44 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 19 Dec 2008 16:57:44 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229705864.35.0.488828395846.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: About the footnote: floor(log(n, 2)) is poor code. This is not supposed to be a dramatic statement, just a statement of fact. Its correctness is dependent on minute details of floating point. It is poor code in exactly the same way that "while x < 1.0: x += 0.1" is poor code---behaviour in boundary cases is almost entirely unpredictable. If 1 + floor(log(n, 2)) happens to give the correct result in the common corner case where x is a power of 2, then that's due to little more than sheer luck. Correct rounding by itself is nowhere near enough to guarantee correct results. In the case of IEEE 754 doubles, a large part of the luck is that the closest double to log(2) just happens to be *smaller* than log(2) itself, so that the implicit division by log(2) in log(x, 2) tends to give a larger result than the true one; if things were the other way around, the formula above would likely fail for many (even small) n. So I don't like seeing this poor code in the Python reference manual, for two reasons: (1) it might get propagated to real world code, and (2) its presence in the docs reflects poorly on the numerical competence of the Python developers. IMO, either: (1) the warning needs to be stronger, or (2) the formulation should be given purely mathematically, without any explicit code, or (3) the formula should be left out of the docs altogether. Mark _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 19:00:12 2008 From: report at bugs.python.org (Eric Smith) Date: Fri, 19 Dec 2008 18:00:12 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229709612.79.0.756951102915.issue4701@psf.upfronthosting.co.za> Changes by Eric Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 19:09:31 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 18:09:31 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229710171.36.0.803168515084.issue4701@psf.upfronthosting.co.za> Changes by Hagen F?rstenau : Added file: http://bugs.python.org/file12403/rangehash3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 19:09:37 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 19 Dec 2008 18:09:37 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229710177.76.0.584595195071.issue4701@psf.upfronthosting.co.za> Changes by Hagen F?rstenau : Removed file: http://bugs.python.org/file12401/rangehash2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 19:16:39 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 19 Dec 2008 18:16:39 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229710599.92.0.832664201838.issue3439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Other possible wording: ... so that ``k`` is approximately ``1 + int(log(abs(x), 2))``. ---------- assignee: marketdickinson -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 19:57:41 2008 From: report at bugs.python.org (Muhammad Alkarouri) Date: Fri, 19 Dec 2008 18:57:41 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1229622024.38.0.169460796479.issue4017@psf.upfronthosting.co.za> Message-ID: Muhammad Alkarouri added the comment: 2008/12/18 Benjamin Peterson : > > Benjamin Peterson added the comment: > > I've uploaded a .dmg for 2.6.1 to > http://www.python.org/ftp/python/2.6.1/. Could you please test it? > Just to confirm, I have installed the package in OS X 10.4.11, and Tkinter and Idle work fine. Many Thanks. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 22:24:07 2008 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Dec 2008 21:24:07 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229721847.32.0.351398738273.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: The origin of the unnecessary hashfunc casts is just me following some of the more specific examples of filling in the tp_hash slot too closely without checking if the cast was still needed. I'll apply and backport Hagen's patches to 3.0 soon (as well as fixing some other non-hashable types such as slice() to use PyHash_NotImplemented), but first I want to understand why range() exhibits this behaviour, while other classes with a superficially similar implementation (such as bytearray) do not. ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 22:33:09 2008 From: report at bugs.python.org (Philip Jenvey) Date: Fri, 19 Dec 2008 21:33:09 +0000 Subject: [issue4702] [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError In-Reply-To: <1229722389.12.0.525860035611.issue4702@psf.upfronthosting.co.za> Message-ID: <1229722389.12.0.525860035611.issue4702@psf.upfronthosting.co.za> New submission from Philip Jenvey : Python 2.6's new msvc9compiler misbehaves when it can't find a compiler (actually a utility of the missing compiler) in its query_vcvarsall() -- it raises an IOError instead of a typical distutils error build tools expect a consistent set of potential exceptions from the compiler suites, such as CCompilerError, DistutilsExecError, DistutilsPlatformError, etc. Distributions like simplejson, Genshi, etc. look for these errors when compiling their optional C extension speedups as an indication that there's no compiler, and to fallback to their pure python counterparts An IOError in this case just doesn't make sense This patch changes them to DistutilsExecErrors. Maybe it should be DistutilsPlatformError -- whatever, just not IOError I think this should be included in 2.6.2 ---------- components: Distutils files: msvc9_ioerror.diff keywords: patch messages: 78070 nosy: pjenvey severity: normal status: open title: [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12404/msvc9_ioerror.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 22:53:42 2008 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 19 Dec 2008 21:53:42 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1229723622.86.0.497543717995.issue4017@psf.upfronthosting.co.za> Changes by Miki Tebeka : ---------- nosy: -tebeka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 23:01:34 2008 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Dec 2008 22:01:34 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229724094.5.0.319346230022.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, the discrepancy with bytearray turns out to be fairly straightforward: bytearray overrides the comparison operations, so inheritance of the default object.__hash__ is automatically blocked. range() objects don't support comparison, so they inherit __hash__ when PyType_Ready is called. Which then begs the question of why range() instances are unhashable only until something happens to invoke the tp_getattro slot on the type object... and it turns out that PyType_Ready isn't called on the type during interpreter startup. Instead, it only happens lazily when one of the operations that needs the tp_dict to be filled in calls PyType_Ready (the default dir() retrieves __dict__ from the type object, and this attribute access causes PyType_Ready to be called). Only at this point is the slot inheritance on the range() type calculated correctly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 23:01:50 2008 From: report at bugs.python.org (Leo M) Date: Fri, 19 Dec 2008 22:01:50 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1229724110.89.0.663571946927.issue4017@psf.upfronthosting.co.za> Changes by Leo M : ---------- nosy: -leoofborg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 23:19:51 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 19 Dec 2008 22:19:51 +0000 Subject: [issue3439] create a numbits() method for int and long types In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1229725191.35.0.164713455653.issue3439@psf.upfronthosting.co.za> Mark Dickinson added the comment: > ... so that ``k`` is approximately ``1 + int(log(abs(x), 2))``. I guess that could work. One other thing: the docs for the trunk seem to suggest that we should be using trunc here, rather than int. I'm looking at: http://docs.python.org/dev/library/stdtypes.html#numeric-types-int- float-long-complex and particularly the note (2), that says of int(x) and long(x): "Deprecated since version 2.6: Instead, convert floats to long explicitly with trunc()." _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 23:43:17 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 19 Dec 2008 22:43:17 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229726597.47.0.0322558474986.issue4701@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Patch looks good to me. ---------- nosy: +amaury.forgeotdarc resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 23:45:20 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 19 Dec 2008 22:45:20 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1229726720.7.0.782037797801.issue4580@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:00:16 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 19 Dec 2008 23:00:16 +0000 Subject: [issue4700] UnicodeEncodeError in license() In-Reply-To: <1229695377.92.0.283252964169.issue4700@psf.upfronthosting.co.za> Message-ID: <1229727616.9.0.611294028145.issue4700@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Fixed in r67859 (trunk), r67860 (py3k) and r67861 (3.0) Thanks for the report! ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:07:51 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 19 Dec 2008 23:07:51 +0000 Subject: [issue4702] [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError In-Reply-To: <1229722389.12.0.525860035611.issue4702@psf.upfronthosting.co.za> Message-ID: <1229728071.87.0.483625841161.issue4702@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I agree with the patch, except that DistutilsPlatformError seems more appropriate - this function is called when the compiler object is configured, before it is used to actually compile files. ---------- nosy: +amaury.forgeotdarc resolution: -> accepted stage: -> patch review versions: +Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:24:11 2008 From: report at bugs.python.org (saa) Date: Fri, 19 Dec 2008 23:24:11 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t, and size calculation needs corrected In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229729051.64.0.809371586198.issue4681@psf.upfronthosting.co.za> saa added the comment: Notes on the problem. The Python mmap documentation says: If length is 0, the maximum length of the map will be the current size of the file when mmap is called. Currently, on a system where off_t is 64-bit and size_t is 32-bit, if the size of the file (st_size) is > 0xFFFF'FFFF, the code will in effect try to map (st_size & 0xFFFF'FFFF). This is suboptimal (imagine if the size of the file is 0x1'0000'1000 or even 0x1'0000'0000). In addition, it seems weird that a caller would have to check the size of the returned mmap against the size of the file to see if the entire file was mapped or not. Finally, it appears that there isn't a reliable, architecture independent, quick, and easy way to figure out what the maximum mmap size is. With these points in mind, I am going to work on coming up with a patch that will change the behavior to simply return an error when a zero length is passed to mmap and the entire file can not be mapped. This will put the onus on the caller to determine an appropriate mmap size for "chunking" the processing of the file, but the behavior will become more consistent. Of course, comments and suggestions are welcome. However, I'm going to have to wrap up my immediate involvement on this in the next couple of days (Yay, vacation!). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:38:17 2008 From: report at bugs.python.org (Ohmi) Date: Fri, 19 Dec 2008 23:38:17 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1229729897.72.0.707111361564.issue4017@psf.upfronthosting.co.za> Ohmi added the comment: Installed on 10.5.6, IDLE ran correctly. Nicely done. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:58:08 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 19 Dec 2008 23:58:08 +0000 Subject: [issue4691] IDLE Code Caching Windows In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za> Message-ID: <1229731088.85.0.445989857093.issue4691@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Reopening: the user did not choose the "-n" option; this option is always set when using "edit with IDLE" Windows shell command. ---------- resolution: invalid -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 01:02:18 2008 From: report at bugs.python.org (Brandon Dixon) Date: Sat, 20 Dec 2008 00:02:18 +0000 Subject: [issue4691] IDLE Code Caching Windows In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za> Message-ID: <1229731338.62.0.237511275543.issue4691@psf.upfronthosting.co.za> Brandon Dixon added the comment: I tested this issue in Linux using the IDLE package (packed separately) from Python. I was not able to reproduce this error, so it appears to be with the Windows version of Python. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:07:09 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Dec 2008 02:07:09 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229738829.61.0.0229929658767.issue4701@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, xrange() is hashable in Py2.6. I believe it was intended that that carry over to Py3.0's range() objects. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:07:58 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Dec 2008 02:07:58 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229738878.36.0.546085505902.issue4701@psf.upfronthosting.co.za> Changes by Raymond Hettinger : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:40:30 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:40:30 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1229740830.89.0.926987945186.issue4533@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:40:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:40:48 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1229740848.67.0.282508191679.issue4565@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:00 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:00 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1229740860.37.0.885987586239.issue1717@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:10 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:10 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1229740870.94.0.864286862962.issue4604@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:17 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:17 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1229740877.16.0.0342566680671.issue4617@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:23 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:23 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1229740883.65.0.227188294738.issue4228@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:31 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:31 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1229740891.12.0.367507546489.issue3248@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:39 +0000 Subject: [issue3767] tkColorChooser may fail if no color is selected In-Reply-To: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za> Message-ID: <1229740899.53.0.34631505557.issue3767@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:45 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1229740905.06.0.309585981041.issue1706039@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:41:56 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:41:56 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229740916.59.0.822913212853.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:42:06 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:42:06 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229740926.13.0.0945160563016.issue4561@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:42:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 02:42:25 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1229740945.87.0.787424927291.issue4449@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 04:06:27 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 20 Dec 2008 03:06:27 +0000 Subject: [issue4669] bytes,join and bytearray.join not in manual; help for bytes.join is wrong. In-Reply-To: <1229329784.58.0.84286765915.issue4669@psf.upfronthosting.co.za> Message-ID: <1229742387.35.0.46271748615.issue4669@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am puzzled as to what you think is missing in the manual. "Bytes and Byte Array Methods Bytes and bytearray objects, being ?strings of bytes?, have all methods found on strings, with the exception of encode(), format() and isidentifier(), which do not make sense with these types. ... Note The methods on bytes and bytearray objects don?t accept strings as their arguments, just as the methods on strings don?t accept bytes as their arguments. For example, " I believe you are right that bytes => bytes/bytearray in the second help entry. ---------- nosy: +tjreedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 04:08:10 2008 From: report at bugs.python.org (Roger) Date: Sat, 20 Dec 2008 03:08:10 +0000 Subject: [issue4703] Syntax error in sample code for enumerate in documentation. In-Reply-To: <1229742490.8.0.685614291877.issue4703@psf.upfronthosting.co.za> Message-ID: <1229742490.8.0.685614291877.issue4703@psf.upfronthosting.co.za> New submission from Roger : Summary: Sample code for enumerate contains a syntax error. The same code reads: >>> for i, season in enumerate(['Spring', 'Summer', 'Fall', 'Winter')]: ... print(i, season) Where the parenthesis and square bracket to the left of the colon in the for line are backwards. It should read: >>> for i, season in enumerate(['Spring', 'Summer', 'Fall', 'Winter']): Where: http://docs.python.org/dev/3.0/library/functions.html ---------- assignee: georg.brandl components: Documentation messages: 78082 nosy: georg.brandl, trenholmes severity: normal status: open title: Syntax error in sample code for enumerate in documentation. versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 04:20:37 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 20 Dec 2008 03:20:37 +0000 Subject: [issue4703] Syntax error in sample code for enumerate in documentation. In-Reply-To: <1229742490.8.0.685614291877.issue4703@psf.upfronthosting.co.za> Message-ID: <1229743237.81.0.125782139669.issue4703@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67865. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 05:07:32 2008 From: report at bugs.python.org (John Machin) Date: Sat, 20 Dec 2008 04:07:32 +0000 Subject: [issue4669] bytes,join and bytearray.join not in manual; help for bytes.join is wrong. In-Reply-To: <1229329784.58.0.84286765915.issue4669@psf.upfronthosting.co.za> Message-ID: <1229746052.17.0.00738454360214.issue4669@psf.upfronthosting.co.za> John Machin added the comment: Terry, you are right. I missed that. My report was based on looking via the index and finding only "(str method)", no "(byte[sarray] method)". _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 05:50:41 2008 From: report at bugs.python.org (saa) Date: Sat, 20 Dec 2008 04:50:41 +0000 Subject: [issue4681] mmap offset should be off_t instead of ssize_t, and size calculation needs corrected In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za> Message-ID: <1229748641.72.0.0983021018491.issue4681@psf.upfronthosting.co.za> saa added the comment: Ok, put a fork in me, 'cuz I'm done with this. The latest is that mmap.size() is defined to return the size of the file and not the size of the data. It tries to return it as a ssize_t, which of course, on systems where off_t is 64-bits and ssize_t is 32-bits, won't work for sizes that won't fit in 32-bits. Without the size of the data, it is unclear how one would traverse a file using the offset parameter. As part of fixing mmap, I would suggest someone should write an example of how it should be used in these cases and use that as a test case. I'm going to leave this up to someone with more knowledge of how this stuff *should* work in Python, but I'm going to go redo my program in C. Thanks for listening and the future efforts. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 07:51:28 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Dec 2008 06:51:28 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229755888.97.0.55180117831.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: It has been pointed out to me that xrange() objects are hashable in 2.x, and since these range objects are immutable, I don't believe there is any driving reason for them not to be hashable. At that point the question becomes one of why xrange() is being initialised correctly in 2.x while something is going wrong with the tp_hash slot initialisation for range() in 3.x that doesn't get fixed until PyType_Ready is called to populate tp_dict. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 07:54:35 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Dec 2008 06:54:35 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229756075.98.0.815920793049.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: Bumping to release blocker for 3.0.1 - until I understand this better, I'm not sure if the xrange->range hashing behaviour change between 2.x and 3.x is a type specific problem or a general issue in the implementation of the new approach to tp_hash inheritance for Py3k. ---------- priority: -> release blocker resolution: accepted -> versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 08:14:40 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Dec 2008 07:14:40 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1229757280.04.0.231257487234.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, I think I figured it out - in 2.x, PyObject_Hash itself includes the fallback to _PyHash_Pointer if none of tp_hash, tp_compare or the tp_richcompare slots have been implemented on the type. So long as a type is only trying to inherit object.__hash__ (as is the case with xrange), then this fallback will do the right thing if PyType_Ready hasn't been called yet. In 3.0, on the other hand, PyObject_Hash has no fallback - if tp_hash isn't filled in, the type isn't considered hashable. This means that for a type to properly inherit hashability in Py3k, PyType_Ready *must* be called on it. Probably the best thing to do is to add xrange and range to the list of types initialised in _Py_ReadyTypes in 2.x and 3.x respectively. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 09:15:39 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Sat, 20 Dec 2008 08:15:39 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229755888.97.0.55180117831.issue4701@psf.upfronthosting.co.za> Message-ID: <494CA9A6.7070108@gmx.net> Hagen F?rstenau added the comment: > I don't believe there is any driving reason for them not to be hashable. On the other hand, what is the use case for hashing objects whose equality is defined as object identity? Python 3.0 (r30:67503, Dec 4 2008, 06:47:38) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(10).__hash__ >>> {range(10), range(10)} {range(0, 10), range(0, 10)} I can see only confusion arising from that. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 11:54:01 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 10:54:01 +0000 Subject: [issue4704] Update pybench for python 3.0 In-Reply-To: <1229770440.73.0.84111592631.issue4704@psf.upfronthosting.co.za> Message-ID: <1229770440.73.0.84111592631.issue4704@psf.upfronthosting.co.za> New submission from Mark Dickinson : pybench needs to be updated for Python 3.0, in particular to remove use of cmp. Here's a patch, against the py3k branch. Questions (mainly for Marc-Andr? Lemburg): 1. Should the version number be bumped for *all* tests, or just for those that have changed? Assuming all tests. 2. Presumably these changes should appear in 3.0.1, and should be backported to 2.x. Backport this to 2.6.2? Or just 2.7? 3. Should I update the sample output in the README file? I was going to just change the PYBENCH 2.0 line to PYBENCH 3.0, but that seems a little bit bogus without updating the rest. ---------- components: Demos and Tools files: pybench3.0.patch keywords: patch messages: 78090 nosy: lemburg, marketdickinson severity: normal status: open title: Update pybench for python 3.0 type: behavior versions: Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12405/pybench3.0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 12:00:33 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 11:00:33 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1229770833.67.0.116613341207.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: Still to do: pybench needs updating to remove a cmp reference; since the changes required for pybench are a little bit more substantial than simple cmp replacement, I've broken this out into a separate issue: issue 4704. There are many uses of cmp still in the Demos directory. How much do we care? The documentation in Doc/extending/newtypes.rst needs updating. I can have a go at this, but Georg would almost certainly do a better job. ---------- dependencies: +Update pybench for python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 12:18:05 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 11:18:05 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1229771885.89.0.786502878258.issue1717@psf.upfronthosting.co.za> Mark Dickinson added the comment: Should Py_CmpToRich (in object.c) disappear? It's currently used in longobject.c, but nowhere else as far as I can tell. It shouldn't be too hard to update longobject.c to remove the use. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 12:19:11 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2008 11:19:11 +0000 Subject: [issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open() In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za> Message-ID: <1229771951.06.0.0886053090665.issue4016@psf.upfronthosting.co.za> STINNER Victor added the comment: > I also think we should consider hard adding more modules > that are loaded at startup time to py3k already huge list. My patch uses tokenize modules in setup.py bootstrap. But it doesn't affect Python classic usage "python" or "python myscript.py". _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 13:32:12 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 20 Dec 2008 12:32:12 +0000 Subject: [issue4704] Update pybench for python 3.0 In-Reply-To: <1229770440.73.0.84111592631.issue4704@psf.upfronthosting.co.za> Message-ID: <494CE5C7.9020306@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-20 11:54, Mark Dickinson wrote: > New submission from Mark Dickinson : > > pybench needs to be updated for Python 3.0, in particular to remove use of > cmp. Here's a patch, against the py3k branch. > > Questions (mainly for Marc-Andr? Lemburg): > > 1. Should the version number be bumped for *all* tests, or just for those > that have changed? Assuming all tests. Just the tests that have been updated. Since there have been a number of small changes, I think it's time to also change the pybench version itself to 2.1 (not 3.0; that's reserved for more major changes). > 2. Presumably these changes should appear in 3.0.1, and should be > backported to 2.x. Backport this to 2.6.2? Or just 2.7? I don't think they should go into 3.0.1 - they are a new feature and not a bug fix. I'll leave that decision to the release manager. Please backport to 2.7 only. > 3. Should I update the sample output in the README file? I was going to > just change the PYBENCH 2.0 line to PYBENCH 3.0, but that seems a little > bit bogus without updating the rest. Please run the suite and add the complete new output. Thanks, -- Marc-Andre Lemburg eGenix.com ________________________________________________________________________ 2008-12-02: Released mxODBC.Connect 1.0.0 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 13:46:08 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Dec 2008 12:46:08 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1229771885.89.0.786502878258.issue1717@psf.upfronthosting.co.za> Message-ID: <1229777165.19755.0.camel@localhost> Antoine Pitrou added the comment: > It shouldn't be too hard to update longobject.c to remove the use. I'll do that one. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 13:46:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Dec 2008 12:46:42 +0000 Subject: [issue4565] io write() performance very slow In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za> Message-ID: <1229777202.92.0.279199804169.issue4565@psf.upfronthosting.co.za> Antoine Pitrou added the comment: We can't solve this for 3.0.1, downgrading to critical. ---------- priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 13:47:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Dec 2008 12:47:04 +0000 Subject: [issue4561] Optimize new io library In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za> Message-ID: <1229777224.59.0.447214414071.issue4561@psf.upfronthosting.co.za> Antoine Pitrou added the comment: We can't solve this for 3.0.1, downgrading to critical. ---------- priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 13:48:45 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Dec 2008 12:48:45 +0000 Subject: [issue4533] 3.0 file.read dreadfully slow In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za> Message-ID: <1229777325.21.0.474570563268.issue4533@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Since it is solved for 3.x and only needs to be bacported to 2.x (where the "io" module isn't the default), downgrading to critical. ---------- nosy: +pitrou priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 14:22:23 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2008 13:22:23 +0000 Subject: [issue3618] possible deadlock in IO library (Lib/io.py) In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za> Message-ID: <1229779343.84.0.678554937836.issue3618@psf.upfronthosting.co.za> STINNER Victor added the comment: I hope that this issue will be fixed by io-c (io library rewritten in C language). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 14:23:50 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Dec 2008 13:23:50 +0000 Subject: [issue3106] speedup some comparisons In-Reply-To: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za> Message-ID: <1229779430.09.0.476385747974.issue3106@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I committed the patch, which will also help #1717. Thanks! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 14:26:23 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Dec 2008 13:26:23 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1229777165.19755.0.camel@localhost> Message-ID: <1229779579.19755.5.camel@localhost> Antoine Pitrou added the comment: > > It shouldn't be too hard to update longobject.c to remove the use. > > I'll do that one. Done in r67871, r67873. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 14:47:23 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2008 13:47:23 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> New submission from STINNER Victor : I like and I need an "unbuffered" standard output which was provided by -u command line option (or PYTHONUNBUFFERED environment variable). Current status of -u option in Python3: the option exists and change the buffer size (disable buffering) of the stdin, stdout and stderr file descriptors. The problem is in initstdio() which creates files with buffering=-1 (default buffer) instead of buffering=0 (no buffering) or buffering=1 (line buffer). But open() enable line buffering of TextIOWrapper is buffering=-1 and the raw file is a tty. Example with py3k trunk: ------------ $ ./python >>> import sys; sys.stdout.line_buffering True $ ./python |cat >>> import sys; sys.stdout.line_buffering False ------------ I would like line buffering when stdout is redirected to a pipe and -u option is used. initstdio() have to be changed to choose buffering option. So it's something like: Index: Python/pythonrun.c =================================================================== --- Python/pythonrun.c (r?vision 67870) +++ Python/pythonrun.c (copie de travail) @@ -810,7 +810,12 @@ #endif } else { - if (!(std = PyFile_FromFd(fd, "", "w", -1, encoding, + int buffering; + if (1) + buffering = 1; /* line */ + else + buffering = -1; /* default */ + if (!(std = PyFile_FromFd(fd, "", "w", buffering, encoding, errors, "\n", 0))) { goto error; } But "if (1)" have to be replaced "if -u option is used" :-) See unbuffered variable of Modules/main.c. ---------- messages: 78102 nosy: haypo severity: normal status: open title: python3.0 -u: unbuffered stdout versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 14:52:48 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2008 13:52:48 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1229781168.97.0.238133833001.issue1068268@psf.upfronthosting.co.za> STINNER Victor added the comment: naufraghi> there are a lot of other places where EINTR naufraghi> can cause and error. Can you write a list of these places? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:03:04 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2008 14:03:04 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229781784.06.0.683867166987.issue4621@psf.upfronthosting.co.za> STINNER Victor added the comment: In the ZIP file format, a filename is a byte string because we don't know the encoding. You can not guess the encoding because it's not stored in the ZIP file and it depends on the OS and the OS configuration. So t1.filename have to be a byte string and testzip.read() have to use bytes and not str. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:06:34 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2008 14:06:34 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229781994.9.0.852933379235.issue4621@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I see that zipfile.py uses the following code to choose the filename encoding: if flags & 0x800: # UTF-8 file names extension filename = filename.decode('utf-8') else: # Historical ZIP filename encoding filename = filename.decode('cp437') So I'm maybe wrong: the encoding is known using a flag? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:09:52 2008 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Sat, 20 Dec 2008 14:09:52 +0000 Subject: [issue4706] try to build a C module, but don't worry if it doesn't work In-Reply-To: <1229782192.75.0.491587462854.issue4706@psf.upfronthosting.co.za> Message-ID: <1229782192.75.0.491587462854.issue4706@psf.upfronthosting.co.za> New submission from Zooko O'Whielacronx : I was trying to install Twisted on my son's OLPC. Twisted comes with a handful of C extensions which are all optional and most of which are not expected to compile on this platform anyway (they are platform-specific for Mac or Windows). If my son's OLPC had a C compiler installed, then it would attempt to build those modules, fail, and proceed to install Twisted. However, since it doesn't have a C compiler, then instead it stops with an error. It would be nice if Twisted could tell distutils to try to build a module, and report whether the build succeeded, but don't stop the entire setup(). http://twistedmatrix.com/trac/ticket/3586 ---------- components: Distutils messages: 78106 nosy: zooko severity: normal status: open title: try to build a C module, but don't worry if it doesn't work _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:18:27 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2008 14:18:27 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229782707.45.0.977119726757.issue4621@psf.upfronthosting.co.za> STINNER Victor added the comment: Test on Ubuntu Gutsy (utf8 file system) with zip 2.32: $ mkdir x $ touch x/h? $ zip -r x.zip x adding: x/ (stored 0%) adding: x/h? (stored 0%) $ python # 3.0 trunk >>> import zipfile >>> testzip = zipfile.ZipFile('x.zip') >>> testzip.infolist()[1].filename 'x/h??' >>> print(ascii(testzip.infolist()[1].filename)) 'x/h\u251c\u2310' Using my own file parse (hachoir-wx), I can see that flags=0 and filename=bytes {78 2f 68 c3 a9} ("x/h?" in UTF-8). You can try x.zip: I attached the file. Added file: http://bugs.python.org/file12406/x.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:19:40 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Dec 2008 14:19:40 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <494CA9A6.7070108@gmx.net> Message-ID: <494CFEEF.8000203@gmail.com> Nick Coghlan added the comment: Hagen F?rstenau wrote: > Hagen F?rstenau added the comment: > >> I don't believe there is any driving reason for them not to be hashable. > > On the other hand, what is the use case for hashing objects whose > equality is defined as object identity? Fast membership testing in sets to track which objects you have and haven't seen, mapping from objects to arbitrary metadata about those objects without having to explicitly redirect through id(), that kind of thing. Generally speaking, the idea is that objects should be hashable if their concept of "equality" cannot change over the life time of the object. Identity based equality meets that criteria, which is why objects (including range/xrange) are hashable by default. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:28:29 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:28:29 +0000 Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za> Message-ID: <1229783309.34.0.729392561665.issue4625@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: +Python 2.6 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:28:46 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:28:46 +0000 Subject: [issue4629] getopt should not accept no_argument that ends with '=' In-Reply-To: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za> Message-ID: <1229783326.68.0.82670792334.issue4629@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:28:54 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:28:54 +0000 Subject: [issue4646] distutils chokes on empty options arg in the setup function In-Reply-To: <1229112904.14.0.0159399234206.issue4646@psf.upfronthosting.co.za> Message-ID: <1229783334.21.0.905173270591.issue4646@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:30:28 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:30:28 +0000 Subject: [issue4670] setup.py exception when db_setup_debug = True In-Reply-To: <1229341792.75.0.0111494669008.issue4670@psf.upfronthosting.co.za> Message-ID: <1229783429.0.0.892552022754.issue4670@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: +Python 2.6 -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:30:41 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:30:41 +0000 Subject: [issue4501] asyncore's urgent data management and connection closed events are broken when using poll() In-Reply-To: <1228266655.05.0.188613442109.issue4501@psf.upfronthosting.co.za> Message-ID: <1229783442.0.0.0506312044153.issue4501@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:30:56 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:30:56 +0000 Subject: [issue4686] Exceptions in ConfigParser don't set .args In-Reply-To: <1229545362.85.0.86911392572.issue4686@psf.upfronthosting.co.za> Message-ID: <1229783456.12.0.640935816308.issue4686@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:35:34 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:35:34 +0000 Subject: [issue4689] Typo in PyObjC URL on "GUI Programming on the Mac" In-Reply-To: <1229558222.99.0.886125304786.issue4689@psf.upfronthosting.co.za> Message-ID: <1229783734.26.0.915115730585.issue4689@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for pointing that out. For the 2.5.3 file release, this was too late; I fixed it in the online copy only. ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:35:51 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:35:51 +0000 Subject: [issue4643] cgitb.html fails if getattr call raises exception In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> Message-ID: <1229783751.71.0.264827509284.issue4643@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:36:03 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:36:03 +0000 Subject: [issue4690] asyncore calls handle_write() on closed sockets when use_poll=True In-Reply-To: <1229560322.27.0.660252722227.issue4690@psf.upfronthosting.co.za> Message-ID: <1229783763.36.0.132073734877.issue4690@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:36:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:36:22 +0000 Subject: [issue4696] email module does not fold headers In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za> Message-ID: <1229783782.54.0.428974802208.issue4696@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:36:35 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:36:35 +0000 Subject: [issue4228] struct.pack('L', -1) In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za> Message-ID: <1229783795.12.0.496294918461.issue4228@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:36:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:36:45 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1229783805.93.0.442013837883.issue3248@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:36:54 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:36:54 +0000 Subject: [issue3767] tkColorChooser may fail if no color is selected In-Reply-To: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za> Message-ID: <1229783814.72.0.208449559535.issue3767@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:37:04 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:37:04 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1229783824.08.0.502941730476.issue1706039@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:37:15 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:37:15 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229783835.33.0.425094841595.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:37:41 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:37:41 +0000 Subject: [issue4010] configure options don't trickle down to distutils In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za> Message-ID: <1229783861.44.0.586164569844.issue4010@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:37:55 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:37:55 +0000 Subject: [issue2996] IDLE "find in files" output not formatted optimally In-Reply-To: <1212008945.94.0.774872087064.issue2996@psf.upfronthosting.co.za> Message-ID: <1229783875.4.0.039388572694.issue2996@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:38:11 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:38:11 +0000 Subject: [issue2996] IDLE "find in files" output not formatted optimally In-Reply-To: <1212008945.94.0.774872087064.issue2996@psf.upfronthosting.co.za> Message-ID: <1229783891.51.0.832636732172.issue2996@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:38:28 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 14:38:28 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1229783908.81.0.480804508594.issue1068268@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.4, Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 16:16:40 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 20 Dec 2008 15:16:40 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1229779579.19755.5.camel@localhost> Message-ID: <494D0C54.6000106@egenix.com> Marc-Andre Lemburg added the comment: Please remember to add back PyUnicode_Compare() if that hasn't already been done. Thanks, -- Marc-Andre Lemburg eGenix.com ________________________________________________________________________ 2008-12-02: Released mxODBC.Connect 1.0.0 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:06:56 2008 From: report at bugs.python.org (Eddie) Date: Sat, 20 Dec 2008 16:06:56 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229789216.22.0.0910707640131.issue4621@psf.upfronthosting.co.za> Eddie added the comment: The problem is not about reading the filenames, but reading the contents of a file with filename that has non-ascii charaters. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:19:14 2008 From: report at bugs.python.org (Alex Stapleton) Date: Sat, 20 Dec 2008 16:19:14 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za> Message-ID: <1229789954.16.0.56126897745.issue4610@psf.upfronthosting.co.za> Alex Stapleton added the comment: I am trying to get a PEP together for this. Does anyone have any thoughts on how to handle comparison between unicode strings in a locale aware situation? Should __lt__ and __gt__ be specified as ignoring locale? In which case do we need to add a new method for doing locale aware comparisons? Should locale be a property of the string, an argument passed to upper/lower/isupper/islower/swapcase/capitalize/sort or global state (locale module...)? Should doing a locale aware comparison of two strings with different locales throw an exception? Should locales be represented as objects or just a string like "en_GB"? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:24:30 2008 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 20 Dec 2008 16:24:30 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za> Message-ID: <1229790270.42.0.713194059412.issue4610@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:42:37 2008 From: report at bugs.python.org (Christian Taylor) Date: Sat, 20 Dec 2008 16:42:37 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> New submission from Christian Taylor : I've been playing around with the newly released Python 3.0, and I'm a bit confused about the built-in round()-function. To sum it up in a single example: Python 3.0 (r30:67503, Dec 7 2008, 04:54:04) [GCC 4.3.2] on linux2 >>> round(25, -1) 30.0 I had expected the result to be the integer 20, because: 1. The documentation on built-in functions says: "values are rounded to the closest multiple of 10 to the power minus n; if two multiples are equally close, rounding is done toward the even choice" 2. Both help(round) and the documentation on built-in functions claim that, if two arguments are given, the return value will be of the same type as the first argument. Is this unintended behaviour, or am I missing something? ---------- components: Interpreter Core messages: 78113 nosy: dingo severity: normal status: open title: round() shows undocumented behaviour type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 18:33:00 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 17:33:00 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229794380.02.0.596532194787.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looks like a bug to me. I get the expected behaviour on my machine. Python 3.0+ (release30-maint:67878, Dec 20 2008, 17:31:44) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> round(25, -1) 20.0 >>> round(25.0, -1) 20.0 What system are you on? ---------- nosy: +marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 19:01:30 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 20 Dec 2008 18:01:30 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229796090.58.0.974850146053.issue4707@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 19:41:05 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 18:41:05 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229798465.38.0.308783924683.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: Correction: it looks like two bugs to me. I think the wrong-return-type bug is rather serious, possibly a release blocker for 3.0.1. I'll see if I can produce a patch. The incorrect rounding (returning 30.0 instead of 20.0) is less serious, but still needs fixing. For a start, we should eliminate the use of pow() in float_round, and when the second argument to round is negative there should be a division by a power of 10 rather than a multiplication by the reciprocal of a power of 10. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 19:41:28 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 18:41:28 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1229789954.16.0.56126897745.issue4610@psf.upfronthosting.co.za> Message-ID: <494D3C55.2060105@v.loewis.de> Martin v. L?wis added the comment: > I am trying to get a PEP together for this. Does anyone have any thoughts > on how to handle comparison between unicode strings in a locale aware > situation? Implementation-wise, or specification-wise? Implementation-wise, you can either try to use the C library, or ICU. For portability, ICU is better; for maintenance, the C library. Specification-wise: it should just Do The Right Thing, and probably be exposed either through the locale module, or through locale objects (in case you want to operate on multiple different locales in a single program) - see other OO languages on how they provide locales. > Should __lt__ and __gt__ be specified as ignoring locale? Yes. > In which case do > we need to add a new method for doing locale aware comparisons? No. Collation is a feature of the locale, not of the strings. > Should locale be a property of the string, an argument passed to > upper/lower/isupper/islower/swapcase/capitalize/sort or global state > (locale module...)? Either global state, or the object *that gets the strings passed to it*. > Should doing a locale aware comparison of two strings with different > locales throw an exception? Strings should not be tied into locales. > Should locales be represented as objects or just a string like "en_GB"? If you want to have multiple of them simultaneously, you need objects. You still need to identify them by name. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 19:43:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 18:43:52 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229798632.33.0.0498141865414.issue4707@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why do you say the return type is incorrect? It should, and does, return a float. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:11:45 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 19:11:45 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229800305.92.0.585797780366.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Why do you say the return type is incorrect? It should, and does, > return a float. The documentation at: http://docs.python.org/dev/3.0/library/functions.html#round says, of round(x[, n]): """The return value is an integer if called with one argument, otherwise of the same type as x.""" On the other hand, PEP 3141 (which I didn't check before) seems to say that you're right: the return value should be an instance of Real. So maybe this is just a doc bug? I have to admit that I don't understand the motivation for round(int, n) returning a float, given that the value will always be integral. It seems that this makes the two-argument version of round less useful to someone who's trying to avoid floats, perhaps working with ints and Decimals, or ints and Rationals, or just implementing fixed-point arithmetic with scaled ints. But given that a behaviour change would be backwards incompatible, and the current behaviour is supported by at least one documentation source, it seems easiest to call this a doc bug. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:14:13 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 19:14:13 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229800453.55.0.434469661719.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: Jeffrey, any opinion on this? ---------- nosy: +jyasskin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:23:30 2008 From: report at bugs.python.org (Christian Taylor) Date: Sat, 20 Dec 2008 19:23:30 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229801010.6.0.944506737817.issue4707@psf.upfronthosting.co.za> Christian Taylor added the comment: I'm using Arch Linux (32 bit) with kernel 2.6.25 and glibc 2.8 on a core 2 duo. The described behaviour occurs in a precompiled binary of Python 3.0, but also in versions I've compiled just now, which includes Python 3.0+ (release30-maint:67879) As far as the rounding itself is concerned, round(x, n) seems to work as documented with n>=0 on my system, while giving the same results as the Python-2.6-version of round() for n<0. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:44:01 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 20 Dec 2008 19:44:01 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229802241.36.0.256514989717.issue4707@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: When PEP 3141 says something should be Real, that includes both int and float as possibilities (since Real is a supertype of Integral), so it's consistent with the PEP for round(int, int) to return an int, and I agree with Mark that round(25, -1) ought to return an int. Making that change would be slightly backwards-incompatible, but IIRC, int is supposed to be usable everywhere float is, so there should be very few programs it would break. So my vote's to change it, for 3.0.1 if possible. The documentation is a little too strict on __round__ implementations by requiring round(x, y) to return the same type as x, but I think it should still encourage __round__ to return the same type. And, uh, oops for writing those bugs. Is your guess for round(25.0, -1)==30.0 that 25.0*(1/10.0) is slightly more than 2.5 on some systems? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:52:51 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 20 Dec 2008 19:52:51 +0000 Subject: [issue4610] Unicode case mappings are incorrect In-Reply-To: <1229789954.16.0.56126897745.issue4610@psf.upfronthosting.co.za> Message-ID: <494D4D10.8040806@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-20 17:19, Alex Stapleton wrote: > Alex Stapleton added the comment: > > I am trying to get a PEP together for this. Does anyone have any thoughts > on how to handle comparison between unicode strings in a locale aware > situation? Some thoughts: * the Unicode implementation *must* stay locale independent * we should implement the Unicode collation algorithm (TR#10, http://unicode.org/reports/tr10/) * which collation to use should be a parameter of a function or object initializer and it should be possible to use multiple collations in the same application (without switching the locale) * the terms "locale" and "collation" should not be mixed; a (default) collation is a property of a locale and there can also be more than one collation per locale The Unicode collation algorithm defines collation in terms of a key function for each collation, so that already fits nicely with the key function parameter of list.sort(). > Should __lt__ and __gt__ be specified as ignoring locale? In which case do > we need to add a new method for doing locale aware comparisons? Unicode strings should not get any locale or collation specific methods. Instead this feature should be implemented elsewhere and the strings in question passed to this new function or object. > Should locale be a property of the string, an argument passed to > upper/lower/isupper/islower/swapcase/capitalize/sort or global state > (locale module...)? No. See above. > Should doing a locale aware comparison of two strings with different > locales throw an exception? No, assigning locales to strings is not going to work and we should not go down that road. It's better to have locale aware functions for certain operations, so that you can pass your Unicode strings to these function instead of binding additional context information to the Unicode strings themselves. > Should locales be represented as objects or just a string like "en_GB"? I think the easiest way to get the collation algorithm implemented is by using a similar scheme as for codecs: you pass a collation name to a central function and get back a collation object that implements the collation in form of a key method and a compare method. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:57:43 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Dec 2008 19:57:43 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229803063.65.0.0470968533801.issue4707@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The code that hands-off long.__round__ to float.__round__ is a train wreck. The intended result can be computed directly and exactly for all sizes of long. ---------- nosy: +rhettinger priority: -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 21:07:03 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 20:07:03 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229803623.94.0.687600491647.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Is your guess for round(25.0, > -1)==30.0 that 25.0*(1/10.0) is slightly more than 2.5 on some > systems? Yes, something like that. I don't think it's feasible to make round perfectly correct (for floats) in all cases without implementing some amount of multiple precision code. But I think we can and should rewrite the code in such a way that it has a pretty good chance of returning correct results in common cases. Small powers of 10 can be computed exactly (up to 10**22, I think), in contrast to reciprocals of powers of 10. I'll work up a patch for round(int, int) -> int, so that at least we have the option of fixing this for 3.0.1 *if* there's general agreement that that's the right way to go. Seems like a python-dev discussion might be necessary to determine that. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 21:41:56 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 20:41:56 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229802241.36.0.256514989717.issue4707@psf.upfronthosting.co.za> Message-ID: <494D5892.2040004@v.loewis.de> Martin v. L?wis added the comment: > When PEP 3141 says something should be Real, that includes both int and > float as possibilities (since Real is a supertype of Integral), so it's > consistent with the PEP for round(int, int) to return an int, and I > agree with Mark that round(25, -1) ought to return an int. In that case, the doc string should be fixed: round(number[, ndigits]) -> floating point number unless "floating point number" is supposed to include type int (which I would find fairly confusing). Wrt. this issue: PEP 3141 specified that round() rounds to even for floats, leaving it explicitly unspecified how ints get rounded. If the result is to be an int, the implementation must not go through floats. It's a problem not only in the border cases, but also for large numbers (which can't get represented correctly even remotely): py> int(round(10**20+324678,-3)) 100000000000000327680 py> int(round(324678,-3)) 325000 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 21:52:59 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Dec 2008 20:52:59 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229806379.14.0.37049427788.issue4707@psf.upfronthosting.co.za> Raymond Hettinger added the comment: IMO, having long.__round__ return a float is a landmine, guaranteed to cause someone problems someday (problems that are hard to find). ---------- priority: critical -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 22:52:00 2008 From: report at bugs.python.org (Fabio Zadrozny) Date: Sat, 20 Dec 2008 21:52:00 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1229809920.86.0.166853829613.issue4705@psf.upfronthosting.co.za> Fabio Zadrozny added the comment: Just as a note, Pydev needs the unbuffered output (or it cannot get it). This has been brought up in the python-dev list: http://mail.python.org/pipermail/python-dev/2008-December/084436.html As a workaround for now I'm using: sys.stdout._line_buffering = True, but that doesn't seem right as it's accessing an internal attribute. ---------- nosy: +fabioz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 23:06:06 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 20 Dec 2008 22:06:06 +0000 Subject: [issue4627] Add Mac OS X Disk Images to Python.org homepage In-Reply-To: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za> Message-ID: <1229810766.85.0.955098958696.issue4627@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I've added installers to the website now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 23:06:46 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 20 Dec 2008 22:06:46 +0000 Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za> Message-ID: <1229810806.0.0.863923732191.issue4017@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Ok. Thanks for testing! I've added the installers to the website. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 23:20:16 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 22:20:16 +0000 Subject: [issue4627] Add Mac OS X Disk Images to Python.org homepage In-Reply-To: <1229810766.85.0.955098958696.issue4627@psf.upfronthosting.co.za> Message-ID: <494D6F9D.1030008@v.loewis.de> Martin v. L?wis added the comment: > I've added installers to the website now. Does that include a 3.0 installer? I can't see any. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 23:40:21 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 20 Dec 2008 22:40:21 +0000 Subject: [issue4627] Add Mac OS X Disk Images to Python.org homepage In-Reply-To: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za> Message-ID: <1229812821.8.0.115704851178.issue4627@psf.upfronthosting.co.za> Benjamin Peterson added the comment: No, I don't have one for 3.0. AFAIK, that hasn't even been attempted yet. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 23:55:51 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Dec 2008 22:55:51 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1229813751.03.0.35304554399.issue1040026@psf.upfronthosting.co.za> Changes by Martin v. L?wis : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 00:39:22 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 20 Dec 2008 23:39:22 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229816362.16.0.891425142984.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a first attempt at a patch for round(int, int) -> int. ---------- keywords: +patch Added file: http://bugs.python.org/file12407/round_int_int.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 01:45:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 21 Dec 2008 00:45:12 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229820312.48.0.436627027854.issue4707@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Correct me if I'm wrong, but I think computing the quotient is not necessary; the remainder is sufficient: def round(n, i): if i >= 0: return n i = 10**(-i) r = n%(2*i) if r < i: return n-r return n-r+2*i _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 02:09:09 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Dec 2008 01:09:09 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229821749.19.0.0927573434533.issue4707@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Martin, that gives some answers like round(51, -2) --> 0 instead of 100. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 02:27:49 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Dec 2008 01:27:49 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229822869.92.0.0940219848333.issue4707@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Will review the patch later this evening. Thanks for the submission. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 03:15:25 2008 From: report at bugs.python.org (Aaron Brady) Date: Sun, 21 Dec 2008 02:15:25 +0000 Subject: [issue4708] os.pipe should return inheritable descriptors (Windows) In-Reply-To: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za> Message-ID: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za> New submission from Aaron Brady : os.pipe should return inheritable descriptors on Windows. Patch below, test attached. New pipe() returns descriptors, which cannot be inherited. However, their permissions are set correctly, so msvcrt.get_osfhandle and msvcrt.open_osfhandle can be used to obtain an inheritable handle. Docs should contain a note to the effect. 'On Windows, use msvcrt.get_osfhandle to obtain a handle to the descriptor which can be inherited. In a subprocess, use msvcrt.open_osfhandle to obtain a new corresponding descriptor.' --- posixmodule_orig.c 2008-12-20 20:01:38.296875000 -0600 +++ posixmodule_new.c 2008-12-20 20:01:54.359375000 -0600 @@ -6481,8 +6481,12 @@ HANDLE read, write; int read_fd, write_fd; BOOL ok; + SECURITY_ATTRIBUTES sAttribs; Py_BEGIN_ALLOW_THREADS - ok = CreatePipe(&read, &write, NULL, 0); + sAttribs.nLength = sizeof( sAttribs ); + sAttribs.lpSecurityDescriptor = NULL; + sAttribs.bInheritHandle = TRUE; + ok = CreatePipe(&read, &write, &sAttribs, 0); Py_END_ALLOW_THREADS if (!ok) return win32_error("CreatePipe", NULL); ---------- components: Library (Lib), Windows files: os_pipe_test.py messages: 78136 nosy: castironpi severity: normal status: open title: os.pipe should return inheritable descriptors (Windows) type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12408/os_pipe_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 03:52:40 2008 From: report at bugs.python.org (Eddie) Date: Sun, 21 Dec 2008 02:52:40 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229827960.95.0.422173850091.issue4621@psf.upfronthosting.co.za> Eddie added the comment: I read again what STINNER Victor and I think that he found another bug. Because, when listing the filenames of that zip file, the names are not displayed correctly. In fact 'x/h??' == 'x/h?'.encode('utf-8').decode('cp437') So, there is again a problem with encodings when reading the contents. The problem here is that when reading one can not give the filename, because is not a key in the NameToInfo dictionary. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 03:58:10 2008 From: report at bugs.python.org (Eddie) Date: Sun, 21 Dec 2008 02:58:10 +0000 Subject: [issue4621] zipfile returns string but expects binary In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za> Message-ID: <1229828290.06.0.662306186738.issue4621@psf.upfronthosting.co.za> Eddie added the comment: Attached is a patch that solves (I hope) the initial problem, the one from Francesco Ricciardi. ---------- keywords: +patch Added file: http://bugs.python.org/file12409/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 06:47:22 2008 From: report at bugs.python.org (Senthil) Date: Sun, 21 Dec 2008 05:47:22 +0000 Subject: [issue4608] urllib.request.urlopen does not return an iterable object In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za> Message-ID: <1229838442.15.0.470411563545.issue4608@psf.upfronthosting.co.za> Senthil added the comment: Here is a patch to fix the issue. Jeremy, is it approach okay? Or do you have any other suggestion? ---------- keywords: +patch Added file: http://bugs.python.org/file12410/issue4608_py31.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 06:47:52 2008 From: report at bugs.python.org (Senthil) Date: Sun, 21 Dec 2008 05:47:52 +0000 Subject: [issue4608] urllib.request.urlopen does not return an iterable object In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za> Message-ID: <1229838472.66.0.0249854561563.issue4608@psf.upfronthosting.co.za> Changes by Senthil : ---------- versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 09:53:34 2008 From: report at bugs.python.org (Cournapeau David) Date: Sun, 21 Dec 2008 08:53:34 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> New submission from Cournapeau David : I believe the current pyport.h for windows x64 has some problems. It does not work for compilers which are not MS ones, because building against the official binary (python 2.6) relies on features which are not enabled unless MS_WIN64 is defined, and the later is not defined if an extension is not built with MS compiler. As a simple example: #include int main() { printf("sizeof(Py_intptr_t) = %d\n", sizeof(Py_intptr_t)); return 0; } If you build this with MS compiler, you get the expected sizeof(Py_intptr_t) = 8, but with gcc, you get 4. Now, if I build the test like: gcc -I C:\Python26\include -DMS_WIN64 main.c Then I got 8 as well. I believe the attached patch should fix the problem (I have not tested it, since building python on amd64). ---------- components: Build files: mingw-w64.patch keywords: patch messages: 78140 nosy: cdavid severity: normal status: open title: Mingw-w64 and python on windows x64 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file12411/mingw-w64.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 10:30:55 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 21 Dec 2008 09:30:55 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229821749.19.0.0927573434533.issue4707@psf.upfronthosting.co.za> Message-ID: <494E0CCB.7080403@v.loewis.de> Martin v. L?wis added the comment: > Martin, that gives some answers like round(51, -2) --> 0 instead of 100. I see. Here is a version that fixes that. def round(n, i): i = 10**(-i) r = n%(2*i) o = i/2 n -= r if r <= o: return n elif r < 3*o: return n+i else: return n+2*i However, I now see that it is pointless not to use divrem, since % computes the quotient as a side effect. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 10:41:54 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 21 Dec 2008 09:41:54 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1229852514.97.0.537065393322.issue4709@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- assignee: -> loewis nosy: +loewis priority: -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 10:43:26 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 21 Dec 2008 09:43:26 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229852606.44.0.562222454447.issue4631@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: critical -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 12:06:02 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 21 Dec 2008 11:06:02 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229857562.28.0.0433753535282.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: Updated patch: fix test_builtin. (Rest of the patch unchanged.) Added file: http://bugs.python.org/file12412/round_int_int2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 14:10:11 2008 From: report at bugs.python.org (Kuba Wieczorek) Date: Sun, 21 Dec 2008 13:10:11 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> New submission from Kuba Wieczorek : This behaviour has been known of course for quite long time. I suppose this is not intentional so I've played a bit with this and I hope you'll consider some little change. Currently, if a ZIP archive contains some subdirectories then zipfile.ZipFile.extract()/extractall() will create files instead of directories in the target location. This of course will lead some scripts to crash (unless any work-around has been done) because files from the subdirectories couldn't be created. Attached is a patch against current 2.7 tree. Applied, will make extractall() extract properly all the contents of the archive with proper tree structure. If a directory name is passed to the extract(), it will only create the directory itself without the contents (I guess it is obvious). ---------- components: Library (Lib) files: zipfile_extract_dirs.patch keywords: patch messages: 78143 nosy: faw severity: normal status: open title: [PATCH] zipfile.ZipFile does not extract directories properly type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file12413/zipfile_extract_dirs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 14:24:51 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Dec 2008 13:24:51 +0000 Subject: [issue4631] urlopen returns extra, spurious bytes In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za> Message-ID: <1229865891.88.0.60862155912.issue4631@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch should have at least a test so that we don't have a regression on this one. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 14:47:37 2008 From: report at bugs.python.org (Daniel Diniz) Date: Sun, 21 Dec 2008 13:47:37 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229867257.39.0.365154881895.issue4707@psf.upfronthosting.co.za> Daniel Diniz added the comment: Hi Mark, I think there's an overflow for ndigits that predates your patch: >>> round(2, -2**31 +1) 2 >>> round(2, -2**31 +2) nan (it looks like these lines above make 2.6 hang :/) Now, I'm getting a segfault in 3.0 when Ctrl + C-ing during a long running round: Python 3.1a0 (py3k:67893M, Dec 21 2008, 10:38:30) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> round(2, -2**31 + 1) 2 >>> round(2, -2**31 + 2) # Press Ctrl + C Segmentation fault (backtrace below) Also, maybe "round(2, -2**31 + 2)" taking long is a bug of its own? The crash with backtrace: Starting program: /home/ajaksu/py3k/python [Thread debugging using libthread_db enabled] Python 3.1a0 (py3k:67893M, Dec 21 2008, 11:08:29) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. [New Thread 0xb7d2e8c0 (LWP 14925)] >>> round(2, -2**31 + 1) 2 >>> >>> round(2, -2**31 + 2) # Press Ctrl + C Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7d2e8c0 (LWP 14925)] _PyUnicode_New (length=10) at Objects/unicodeobject.c:359 359 unicode->str[0] = 0; (gdb) bt #0 _PyUnicode_New (length=10) at Objects/unicodeobject.c:359 #1 0x080708a5 in PyUnicodeUCS2_DecodeUTF8Stateful (s=0x813d8dc "last_value", size=10, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:2022 #2 0x08072e22 in PyUnicodeUCS2_FromStringAndSize (u=0x813d8dc "last_value", size=10) at Objects/unicodeobject.c:2000 #3 0x08072f82 in PyUnicodeUCS2_FromString (u=0x813d8dc "last_value") at Objects/unicodeobject.c:557 #4 0x0810ddf7 in PyDict_SetItemString (v=0xb7b21714, key=0x813d8dc "last_value", item=0xb7a4e43c) at Objects/dictobject.c:2088 #5 0x080b5fb1 in PySys_SetObject (name=0x813d8dc "last_value", v=0xa) at Python/sysmodule.c:67 #6 0x080afedb in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1294 #7 0x080b063c in PyRun_InteractiveOneFlags (fp=0xb7e7a440, filename=0x813f509 "", flags=0xbf84bd34) at Python/pythonrun.c:1189 #8 0x080b0816 in PyRun_InteractiveLoopFlags (fp=0xb7e7a440, filename=0x813f509 "", flags=0xbf84bd34) at Python/pythonrun.c:909 #9 0x080b0fa2 in PyRun_AnyFileExFlags (fp=0xb7e7a440, filename=0x813f509 "", closeit=0, flags=0xbf84bd34) at Python/pythonrun.c:878 #10 0x080bc49a in Py_Main (argc=0, argv=0x8192008) at Modules/main.c:611 #11 0x0805a1dc in main (argc=1, argv=0xbf84de24) at ./Modules/python.c:70 I hope this helps :) Daniel ---------- nosy: +ajaksu2 versions: +Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 15:37:12 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 21 Dec 2008 14:37:12 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229870232.81.0.256301936069.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: > >>> round(2, -2**31 + 2) # Press Ctrl + C > Segmentation fault > (backtrace below) Thanks, Daniel. It looks like I messed up the refcounting in the error- handling section of the code. I'll fix this. I don't think the hang itself should be considered a bug, any more than the hang from "10**(2**31-1)" is a bug. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 15:55:53 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 21 Dec 2008 14:55:53 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229871353.97.0.0822058837957.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: Cause of segfault was doing Py_XDECREF on a pointer that hadn't been initialised to NULL. Here's a fixed patch. I still get the instant result: >>> round(2, -2**31+1) 2 which is a little odd. It's the correct result, but I can't see how it gets there: under the current algorithm, there should be a 10**(2**31-1) happening somewhere, and that would take a *lot* of time and memory. Will investigate. Added file: http://bugs.python.org/file12414/round_int_int3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 16:28:13 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 21 Dec 2008 15:28:13 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229873293.54.0.130816370062.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: Aha. The special result for round(x, 1-2**31) has nothing to do with this particular patch. It's a consequence of: #define UNDEF_NDIGITS (-0x7fffffff) /* Unlikely ndigits value */ in bltinmodule.c. The same behaviour results for all types, not just ints. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 16:44:06 2008 From: report at bugs.python.org (Daniel Diniz) Date: Sun, 21 Dec 2008 15:44:06 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229874246.48.0.335107500723.issue4707@psf.upfronthosting.co.za> Daniel Diniz added the comment: Mark Dickinson wrote: > I don't think the hang itself should be considered a bug, any more > than the hang from "10**(2**31-1)" is a bug. Well, besides the fact that you can stop "10**(2**31-1)" with Ctrl+C but not round(2, -2**31+1), the round case may special case ndigits > number to avoid the slow pow(10, x). >>>> round(2, -2**31+1) > 2 > > which is a little odd. It's the correct result, but I can't see how Is it correct? The answer for 0 > ndigits > -2**301+1 was nan before the patch, 0 after. Given that "round(2, 2**31)" throws an OverflowError, iff this is wrong, should it OverflowError too? > it gets there: under the current algorithm, there should be a > 10**(2**31-1) happening somewhere, and that would take a *lot* of time > and memory. Will investigate. That should be optimizable for ndigits > number, and perhaps log10(number) < k * ndigits (for large ndigits), right? But I don't think it's a realworld usecase, so dropping this idea for 2.6. > Aha. The special result for round(x, 1-2**31) has nothing to do > with this particular patch. It's a consequence of: Yep, "predates your patch" as I said :) ---------- versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 17:14:21 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 21 Dec 2008 16:14:21 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229876061.29.0.309751430115.issue4707@psf.upfronthosting.co.za> Mark Dickinson added the comment: > [Me] > > which is a little odd. It's the correct result, but I can't see how [Daniel] > Is it correct? No. :-) It should be 0, as you say. > Given that "round(2, 2**31)" throws an OverflowError I think this is wrong, too. It should be 2. It's another consequence of the code in bltinmodule.c. The builtin_round function seems unnecessarily complicated: it converts the second argument from a Python object to a C int, then converts it back again before calling the appropriate __round__ method. Then the first thing the __round__ method typically does for built-in types is to convert to a C int again. As far as I can tell the first two conversions are unnecessary. Here's an updated version of the patch that does away with the unnecessary conversions, along with the UNDEF_NDIGITS hack. All tests still pass, on my machine, and with this patch I get the results I'd expect: >>> round(2, 2**31) 2 >>> round(2, 2**100) 2 >>> round(2, -2**100) ^CTraceback (most recent call last): File "", line 1, in KeyboardInterrupt >> round(2, 1-2**31) ^CTraceback (most recent call last): File "", line 1, in KeyboardInterrupt > That should be optimizable for ndigits > number, and perhaps > log10(number) < k * ndigits (for large ndigits), right? But I don't > think it's a realworld usecase, so dropping this idea for 2.6. Agreed. I don't think this optimization is worth it. Added file: http://bugs.python.org/file12415/round_int_int4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 17:55:53 2008 From: report at bugs.python.org (Scott Dial) Date: Sun, 21 Dec 2008 16:55:53 +0000 Subject: [issue4711] Wide literals in the table of contents overflow in documentation In-Reply-To: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za> Message-ID: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za> New submission from Scott Dial : There is a problem with the table contents with respect to literals that cannot be word-wrapped. I see this issue here: http://docs.python.org/dev/2.6/library/multiprocessing.html The line in the table of contents that reads "The multiprocessing.dummy module" is broken in that the literal "multiprocessing.sharedctypes" overflows into the right-hand side. It also ends up underneath the contents on the right, which makes it extra hard to know what that entry was about. This instance may be browser specific, but I think it brings up a more general question of what should be done with such long literals and how overflow should be handled. And perhaps even whether it is wise to have set the width of that div to such a narrow and specific value (230px). I've attached a screenshot from Firefox 2.0.0.20/Win32 in case it is not as reproducible as I would expect. ---------- assignee: georg.brandl components: Documentation files: multiprocessing.png messages: 78151 nosy: georg.brandl, scottdial severity: normal status: open title: Wide literals in the table of contents overflow in documentation type: behavior Added file: http://bugs.python.org/file12416/multiprocessing.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 18:07:32 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 21 Dec 2008 17:07:32 +0000 Subject: [issue4666] test_bad_address in test_urllib2_localnet often fails In-Reply-To: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za> Message-ID: <1229879252.92.0.163369270146.issue4666@psf.upfronthosting.co.za> Roumen Petrov added the comment: Tests (trunk 21 dec 2008) fail as before (i.e. test_curses, test_urllib2_localnet and test_urllibnet) but now test_smtplib fail too. Single test always succeed as example: $ echo test_smtplib > /tmp/pynexttest $ ./python -E -tt ../Lib/test/regrtest.py -l -s test_smtplib 1 test OK. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 18:20:15 2008 From: report at bugs.python.org (Valery) Date: Sun, 21 Dec 2008 17:20:15 +0000 Subject: [issue1712522] urllib.quote throws exception on Unicode URL Message-ID: <1229880015.82.0.729793457517.issue1712522@psf.upfronthosting.co.za> Valery added the comment: Hi, gurus, can anyone then give a hint what we mortals should use in order to form the URL with non-ascii symbols? We loved so much idea to feed our national symbols to urllib.quote as unicode string... and now we are quite disoriented... Thanks in advance for any comments! Valery ---------- nosy: +vak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 18:24:05 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 21 Dec 2008 17:24:05 +0000 Subject: [issue4712] Document pickle behavior for subclasses of dicts/lists In-Reply-To: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za> Message-ID: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za> New submission from Georg Brandl : When unpickling dict subclasses, the dict is filled via setitem before __setstate__ is called. This, and other behavior around subclasses of classes that have special pickle behavior should be documented. ---------- assignee: georg.brandl components: Documentation messages: 78154 nosy: aronacher, georg.brandl priority: low severity: normal stage: needs patch status: open title: Document pickle behavior for subclasses of dicts/lists type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 18:57:26 2008 From: report at bugs.python.org (Valery) Date: Sun, 21 Dec 2008 17:57:26 +0000 Subject: [issue1712522] urllib.quote throws exception on Unicode URL Message-ID: <1229882246.98.0.0957947060992.issue1712522@psf.upfronthosting.co.za> Valery added the comment: (self-answer to msg78153) the working recipe is: http://www.nabble.com/Re:-Problem:-neither-urllib2.quote-nor- urllib.quote-encode-the--unicode-strings-arguments-p19823144.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 22:30:07 2008 From: report at bugs.python.org (Christoph Zwerschke) Date: Sun, 21 Dec 2008 21:30:07 +0000 Subject: [issue4713] Installing sgmlop can crash xmlrpclib In-Reply-To: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za> Message-ID: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za> New submission from Christoph Zwerschke : If you install sgmlop (downloadable from http://effbot.org/downloads/#sgmlop) under Python 2.x, then this can break xmlrpclib. You can reproduce this problem as follows (I have tested with Py 2.4, 2.5 and 2.6): ------------ data = """ f käse """ import xmlrpclib assert xmlrpclib.FastParser is None print xmlrpclib.SgmlopParser and 'with' or 'without', 'sgmlop' assert xmlrpclib.loads(data) == ((u'k\xe4se',), 'f') ------------ If sgmlop is installed, this gives a UnicodeDecodeError, otherwise everything works well. This happens because xmlrpclib prefers using sgmlop over lib.parsers.expat, but fails to handle numeric character entities properly with this parser. Find attached a patch that fixes this problem. I also wonder whether lib.parsers.expat shouldn't be preferred over sgmlop, since the latter is somewhat outdated, and installing external libraries should not cause crashes or wrong behavior of standard lib modules (see also Issue1772916 for a similar problem). ---------- components: Library (Lib) messages: 78156 nosy: cito severity: normal status: open title: Installing sgmlop can crash xmlrpclib type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 22:37:37 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Dec 2008 21:37:37 +0000 Subject: [issue4714] print opcode stats at the end of pybench runs In-Reply-To: <1229895457.43.0.758313096043.issue4714@psf.upfronthosting.co.za> Message-ID: <1229895457.43.0.758313096043.issue4714@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This patch prints opcode statistics at the end of a pybench run if DYNAMIC_EXECUTION_PROFILE has been enabled when compiling the interpreter. Is it ok? Is it better to add it to the Benchmark class? ---------- components: Demos and Tools files: pybench-opcodestats.patch keywords: patch messages: 78157 nosy: lemburg, pitrou priority: normal severity: normal stage: patch review status: open title: print opcode stats at the end of pybench runs type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file12417/pybench-opcodestats.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 22:38:13 2008 From: report at bugs.python.org (Christoph Zwerschke) Date: Sun, 21 Dec 2008 21:38:13 +0000 Subject: [issue4713] Installing sgmlop can crash xmlrpclib In-Reply-To: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za> Message-ID: <1229895493.77.0.194148637344.issue4713@psf.upfronthosting.co.za> Changes by Christoph Zwerschke : ---------- keywords: +patch Added file: http://bugs.python.org/file12418/xmlrpclib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 23:33:42 2008 From: report at bugs.python.org (Koen van de Sande) Date: Sun, 21 Dec 2008 22:33:42 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1229898822.99.0.900682614504.issue4710@psf.upfronthosting.co.za> Koen van de Sande added the comment: I'm no expert, but is it possible for ZIP files to have Windows-style path seperators ('\') as well? And is this new behavior desirable for existing code as well? It might break existing applications, so perhaps a new extractrecursive() function is more intuitive. Finally, I've noticed that the patch does not add any tests to test for the new/old behavior. ---------- nosy: +koen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 23:58:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Dec 2008 22:58:05 +0000 Subject: [issue4715] optimize bytecode for conditional branches In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za> Message-ID: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This patch optimizes the bytecode for conditional branches. For example, the list comprehension "[x for x in l if not x]" produced the following bytecode: 1 0 BUILD_LIST 0 3 LOAD_FAST 0 (.0) >> 6 FOR_ITER 23 (to 32) 9 STORE_FAST 1 (x) 12 LOAD_FAST 1 (x) 15 JUMP_IF_TRUE 10 (to 28) 18 POP_TOP 19 LOAD_FAST 1 (x) 22 LIST_APPEND 2 25 JUMP_ABSOLUTE 6 >> 28 POP_TOP 29 JUMP_ABSOLUTE 6 >> 32 RETURN_VALUE but after the patch it produces the following bytecode: 1 0 BUILD_LIST 0 3 LOAD_FAST 0 (.0) >> 6 FOR_ITER 18 (to 27) 9 STORE_FAST 1 (x) 12 LOAD_FAST 1 (x) 15 POP_JUMP_IF_TRUE 6 18 LOAD_FAST 1 (x) 21 LIST_APPEND 2 24 JUMP_ABSOLUTE 6 >> 27 RETURN_VALUE Notice that not only the code is shorter, but the conditional jump (POP_JUMP_IF_TRUE) jumps right to the start of the loop instead of going through the JUMP_ABSOLUTE at the end. "continue" statements are helped similarly. Furthermore, the old jump opcodes (JUMP_IF_FALSE, JUMP_IF_TRUE) could profitably be replaced by two new opcodes: - one which jumps if true and pops otherwise - one which jumps if false and pops otherwise ---------- components: Interpreter Core files: condbranches.patch keywords: patch messages: 78159 nosy: pitrou severity: normal stage: patch review status: open title: optimize bytecode for conditional branches type: resource usage versions: Python 3.1 Added file: http://bugs.python.org/file12419/condbranches.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 00:03:28 2008 From: report at bugs.python.org (Kuba Wieczorek) Date: Sun, 21 Dec 2008 23:03:28 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1229900608.76.0.344807729934.issue4710@psf.upfronthosting.co.za> Kuba Wieczorek added the comment: I'm not sure if it would make sense to save current extract()/extractall() behaviour and implement new with another function because current one is simply faulty. And if it's about BC breaks then well... it may be introduced in 3.0 line, I think that leaving faulty behaviour and introducing another with another function misses the point. AFAIK there'd be no problem with Windows-style paths but to be sure I revised my patch. Yes, I'm sorry for the lack of tests, it is my first patch and I forgot about this. I'll write them in a couple of hours. Added file: http://bugs.python.org/file12420/zipfile_extract_dirs_r2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 00:35:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 21 Dec 2008 23:35:22 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1229902522.92.0.69731387281.issue1706039@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Unfortunately, the patch is broken. The program fname='test123' f=open(fname,'w') f.read() crashes with the patch applied. I think I will revert the patch in 2.5.3, release 2.5.4, and reject the patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 00:42:49 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sun, 21 Dec 2008 23:42:49 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1229902969.15.0.878875875084.issue1706039@psf.upfronthosting.co.za> Guilherme Polo added the comment: It isn't being careful when calling PyErr_SetFromErrno inside the Py_UniversalNewlineFread function since this function is being called all over fileobject after releasing the GIL.. so, isn't this just a matter of adding pairs of PyGILState_Ensure/PyGILState_Release around these calls to PyErr_SetFromErrno in this specific function ? ---------- nosy: +gpolo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 00:52:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 21 Dec 2008 23:52:13 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state In-Reply-To: <1229902969.15.0.878875875084.issue1706039@psf.upfronthosting.co.za> Message-ID: <494ED6AA.9080609@v.loewis.de> Martin v. L?wis added the comment: > It isn't being careful when calling PyErr_SetFromErrno inside the > Py_UniversalNewlineFread function since this function is being called > all over fileobject after releasing the GIL.. so, isn't this just a > matter of adding pairs of PyGILState_Ensure/PyGILState_Release around > these calls to PyErr_SetFromErrno in this specific function ? Perhaps that could fix this problem (or perhaps not - is PyGILState_Ensure guaranteed to do the right thing, even in the presence of multiple interpreters?) My concern is that this patch may contain other bugs. I am apparently incapable of reviewing it correctly, and nobody else has offered a careful review. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 00:55:26 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sun, 21 Dec 2008 23:55:26 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state In-Reply-To: <494ED6AA.9080609@v.loewis.de> Message-ID: Guilherme Polo added the comment: On Sun, Dec 21, 2008 at 9:52 PM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > >> It isn't being careful when calling PyErr_SetFromErrno inside the >> Py_UniversalNewlineFread function since this function is being called >> all over fileobject after releasing the GIL.. so, isn't this just a >> matter of adding pairs of PyGILState_Ensure/PyGILState_Release around >> these calls to PyErr_SetFromErrno in this specific function ? > > Perhaps that could fix this problem (or perhaps not - is > PyGILState_Ensure guaranteed to do the right thing, even in the > presence of multiple interpreters?) It is said to be unsupported in that case, but I guess you knew that. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 02:49:52 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 01:49:52 +0000 Subject: [issue4715] optimize bytecode for conditional branches In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za> Message-ID: <1229910592.51.0.945951799274.issue4715@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an optional patch which provides the two opcodes I was talking about (I've called them POP_OR_JUMP and JUMP_OR_POP). Together with a bit of work on the peepholer they make the bytecode expression of boolean calculations very concise. A somewhat contrived example: "f = lambda x,y,z,v: (z if x else y) or v" Without the patch: 1 0 LOAD_FAST 0 (x) 3 JUMP_IF_FALSE 7 (to 13) 6 POP_TOP 7 LOAD_FAST 2 (z) 10 JUMP_FORWARD 4 (to 17) >> 13 POP_TOP 14 LOAD_FAST 1 (y) >> 17 JUMP_IF_TRUE 4 (to 24) 20 POP_TOP 21 LOAD_FAST 3 (v) >> 24 RETURN_VALUE With the patch: 1 0 LOAD_FAST 0 (x) 3 POP_JUMP_IF_FALSE 12 6 LOAD_FAST 2 (z) 9 JUMP_FORWARD 3 (to 15) >> 12 LOAD_FAST 1 (y) >> 15 JUMP_OR_POP 21 18 LOAD_FAST 3 (v) >> 21 RETURN_VALUE Added file: http://bugs.python.org/file12421/condbranches-plus.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 03:57:38 2008 From: report at bugs.python.org (hippietrail) Date: Mon, 22 Dec 2008 02:57:38 +0000 Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za> Message-ID: <1229914658.83.0.319908263041.issue3297@psf.upfronthosting.co.za> Changes by hippietrail : ---------- nosy: +hippietrail _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 04:03:24 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Mon, 22 Dec 2008 03:03:24 +0000 Subject: [issue4708] os.pipe should return inheritable descriptors (Windows) In-Reply-To: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za> Message-ID: <1229915004.97.0.528670469965.issue4708@psf.upfronthosting.co.za> Gabriel Genellina added the comment: >From the thread in c.l.p: Pros (of changing os.pipe() to return inheritable pipes): - as it isn't explicitely documented whether os.pipe() returns inheritable pipes or not, both versions are "right" according to the documentation. - if someone relies on pipes being non-inheritable on Windows (why?), this is undocumented behaviour, and Python has the right to change it. - would improve POSIX compatibility, it mimics what os.pipe() does on those OS - inheritable pipes are less surprising for guys coming from other OS - inheritable pipes are a lot more useful than non-inheritable ones when doing IPC (probably its main usage). Cons: - os.pipe has behaved that way since long time ago. - some programs *might* break, if they relied on pipes being non-inheritable on Windows, even if that was undocumented behaviour. ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 09:45:17 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 22 Dec 2008 08:45:17 +0000 Subject: [issue4707] round() shows undocumented behaviour In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za> Message-ID: <1229935517.67.0.229692021952.issue4707@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 11:05:52 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 22 Dec 2008 10:05:52 +0000 Subject: [issue4714] print opcode stats at the end of pybench runs In-Reply-To: <1229895457.43.0.758313096043.issue4714@psf.upfronthosting.co.za> Message-ID: <494F667D.6000301@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-21 22:37, Antoine Pitrou wrote: > New submission from Antoine Pitrou : > > This patch prints opcode statistics at the end of a pybench run if > DYNAMIC_EXECUTION_PROFILE has been enabled when compiling the interpreter. > > Is it ok? Is it better to add it to the Benchmark class? I don't think it's worth doing this for low-level and highly artificial benchmarks like the ones run by pybench. Opcode statistics are much better taken in real life applications, e.g. let Django, Zope, etc. run for a day or two and then look at the opcode statistics. If at all, then opcode statistics should be an optional feature enabled by a command line switch. I'd then create new methods bench.start_opcode_stats(), bench.stop_opcode_stats() and bench.get_opcode_stats(). Also note that this line will result in wrong results: + if opstats: + opstats = [new - old + for new, old in zip(sys.getdxp(), opstats)] It should be: start_opstats = sys.getdxp() ... stop_opstats = sys.getdxp() opstats = [new_value - old_value for new_value, old_value in zip(stop_opstats, start_opstats] _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 11:15:17 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 10:15:17 +0000 Subject: [issue4714] print opcode stats at the end of pybench runs In-Reply-To: <494F667D.6000301@egenix.com> Message-ID: <1229940895.6263.5.camel@localhost> Antoine Pitrou added the comment: > I don't think it's worth doing this for low-level and highly > artificial benchmarks like the ones run by pybench. Well, it can help to know which opcodes are executed when running a particular bunch of sub-tests :) > If at all, then opcode statistics should be an optional feature > enabled by a command line switch. I'd then create new methods > bench.start_opcode_stats(), bench.stop_opcode_stats() and > bench.get_opcode_stats(). > > Also note that this line will result in wrong results: > > + if opstats: > + opstats = [new - old > + for new, old in zip(sys.getdxp(), opstats)] You are right, my assumption was simply that the error would be in the noise. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:09:06 2008 From: report at bugs.python.org (Fabio Zadrozny) Date: Mon, 22 Dec 2008 11:09:06 +0000 Subject: [issue4716] Python 3.0 halts on shutdown when settrace is set In-Reply-To: <1229944146.69.0.613877137046.issue4716@psf.upfronthosting.co.za> Message-ID: <1229944146.69.0.613877137046.issue4716@psf.upfronthosting.co.za> New submission from Fabio Zadrozny : In Python 3.0, the interpreter will not shutdown properly after setting a tracing function and something goes into stdout. The code attached shows the problem in action: just execute it and notice how the interpreter will be kept running after the code has been executed. There are some more things that need to be considered: - If the print('here') is not called, it will shutdown - If BOTH the print('here') and the sys.settrace(None) is not called, it will NOT shutdown Note: I've marked the bug as crash because it's halting, but maybe there could be a better alternative for it... ---------- components: Interpreter Core files: tracing_test.py messages: 78169 nosy: fabioz severity: normal status: open title: Python 3.0 halts on shutdown when settrace is set type: crash versions: Python 3.0 Added file: http://bugs.python.org/file12422/tracing_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:24:58 2008 From: report at bugs.python.org (Fabio Zadrozny) Date: Mon, 22 Dec 2008 11:24:58 +0000 Subject: [issue4717] execfile conversion is not correct In-Reply-To: <1229945098.56.0.809169461336.issue4717@psf.upfronthosting.co.za> Message-ID: <1229945098.56.0.809169461336.issue4717@psf.upfronthosting.co.za> New submission from Fabio Zadrozny : In 2to3, execfile(file, globals, locals) is translated to exec(open(file).read(), globals, locals) But that's not correct, as the actual file from the executed code gets wrong with that. The correct thing would be: exec(compile(open(file).read(), file, 'exec'), globals, locals) So that the name of the file remains correct in the module that's being run. ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 78170 nosy: fabioz severity: normal status: open title: execfile conversion is not correct versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:30:58 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Mon, 22 Dec 2008 11:30:58 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> New submission from Dmitry Vasiliev : It seems the wsgiref package was copied from Python 2.* without any modifications. There are already 3 issues about that but they only describe a part of the problem so I decided to start a new one. The issues was: http://bugs.python.org/issue3348 http://bugs.python.org/issue3795 http://bugs.python.org/issue4522 The attached patch fix the problem with the following changes: - Fixed headers handling in wsgiref/simple_server.py; - Fixed encoding problems. Now WSGI applications must return iterable with bytes but start_response() allow status and headers as bytes and as strings. "wsgi.input" file-like now use BytesIO instead of StringIO; - Fixed tests; - Updated documentation examples; ---------- components: Library (Lib) files: wsgiref.patch keywords: patch messages: 78171 nosy: hdima severity: normal status: open title: wsgiref package totally broken type: crash versions: Python 3.0 Added file: http://bugs.python.org/file12423/wsgiref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:40:29 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 11:40:29 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1229946029.65.0.750451834811.issue4718@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Phillip, do you have time to take a look at it? We really *must* fix wsgiref in py3k... ---------- nosy: +pitrou, pje priority: -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:46:45 2008 From: report at bugs.python.org (Fabio Zadrozny) Date: Mon, 22 Dec 2008 11:46:45 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> New submission from Fabio Zadrozny : sys.exc_clear() does not seem to exist in Python 3.0 anymore, so, a way to deal with it should be provided (maybe put a #TODO comment and point to somewhere explaining what happened?). ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 78173 nosy: fabioz severity: normal status: open title: sys.exc_clear() not flagged in any way versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:50:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 11:50:39 +0000 Subject: [issue4716] Python 3.0 halts on shutdown when settrace is set In-Reply-To: <1229944146.69.0.613877137046.issue4716@psf.upfronthosting.co.za> Message-ID: <1229946639.44.0.344923531138.issue4716@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I haven't investigated, but in py3k print() has currently bits written in Python, which means it will get (recursively) traced when called from the trace function. It can of course have all kinds of funny implications! ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:52:08 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 11:52:08 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229946728.99.0.39800178686.issue4719@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There should be no need for sys.exc_clear() anymore. What are you trying to achieve? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:52:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 11:52:39 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229946759.5.0.016382427513.issue4719@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In any case, probably a documentation issue :)) ---------- assignee: -> georg.brandl components: +Documentation -2to3 (2.x to 3.0 conversion tool) nosy: +georg.brandl priority: -> normal type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 13:33:00 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 22 Dec 2008 12:33:00 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229949180.69.0.724630465664.issue4719@psf.upfronthosting.co.za> Georg Brandl added the comment: exc_clear() is not in the 3.0 docs, and the whatsnew contains a note. Maybe a 2to3 issue? ---------- assignee: georg.brandl -> benjamin.peterson components: +2to3 (2.x to 3.0 conversion tool) -Documentation nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 13:48:14 2008 From: report at bugs.python.org (Fabio Zadrozny) Date: Mon, 22 Dec 2008 12:48:14 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229950094.55.0.897659061854.issue4719@psf.upfronthosting.co.za> Fabio Zadrozny added the comment: When created it was already marked as a 2to3 issue (in the components), so, for clarity, yes: it's a 2to3 issue (what should the user do with that when porting... I think that the 2to3 should do something regarding that... maybe just changing it for a 'pass'?). Also, the docs say it was removed, but they don't leave clear that it's not needed because no info is stored anymore (because that was needed just to clear the frame that was kept alive when an exception was raised -- so, note that I'm assuming that issue was fixed and it's not needed anymore, but the docs don't make that clear) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 13:49:23 2008 From: report at bugs.python.org (Pearu Peterson) Date: Mon, 22 Dec 2008 12:49:23 +0000 Subject: [issue4720] Extension function optional argument specification | causes RuntimeError In-Reply-To: <1229950163.26.0.0772490400351.issue4720@psf.upfronthosting.co.za> Message-ID: <1229950163.26.0.0772490400351.issue4720@psf.upfronthosting.co.za> New submission from Pearu Peterson : Calling the following extension function static PyObject * baz(PyObject *self, PyObject *args, PyObject *keywds) { static char *kwlist[] = {NULL}; if (!PyArg_ParseTupleAndKeywords(args,keywds,"|:bar.baz", kwlist)) return NULL; return Py_BuildValue(""); } raises RuntimeError: more argument specifiers than keyword list entries (remaining format:'|:bar.baz') in Python 2.6 but it used to work with earlier versions of Python. This bug breaks all f2py generated extension modules when using Python 2.6. ---------- components: Extension Modules files: barmodule.c messages: 78179 nosy: pearu severity: normal status: open title: Extension function optional argument specification | causes RuntimeError type: crash versions: Python 2.6 Added file: http://bugs.python.org/file12424/barmodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 13:59:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 12:59:36 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229950094.55.0.897659061854.issue4719@psf.upfronthosting.co.za> Message-ID: <1229950754.6263.9.camel@localhost> Antoine Pitrou added the comment: Le lundi 22 d?cembre 2008 ? 12:48 +0000, Fabio Zadrozny a ?crit : > Fabio Zadrozny added the comment: > > When created it was already marked as a 2to3 issue Oops, sorry. > (because that was needed > just to clear the frame that was kept alive when an exception was raised To clear the frame and the exception object itself, yes. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 14:30:12 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 13:30:12 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229952612.45.0.772030066222.issue4719@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Actually, I think this should just get a Py3k warning in 2.6 and 2.7. 2to3 doesn't deal with anything else that has been removed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 14:44:53 2008 From: report at bugs.python.org (Fabio Zadrozny) Date: Mon, 22 Dec 2008 13:44:53 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229953493.85.0.258889083126.issue4719@psf.upfronthosting.co.za> Fabio Zadrozny added the comment: > 2to3 doesn't deal with anything else that has been removed. That seems a bit odd for me... isn't it the perfect place for that? (it doesn't even need to change the code for a pass, but it could give the user some warning about it at that specific line -- maybe with a pointer to a place explaining why it was removed). I think that if 2to3 flags it, it can make the porting cycle faster than having to run the code (and expecting a huge code-coverage) to get those -- especially as sys.exc_clear is mostly used in cases where you are expecting some exception... and I believe not everyone gives as much emphasis for exception cases as they'd for the cases in the 'regular flow' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 15:07:20 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 22 Dec 2008 14:07:20 +0000 Subject: [issue4704] Update pybench for python 3.0 In-Reply-To: <1229770440.73.0.84111592631.issue4704@psf.upfronthosting.co.za> Message-ID: <1229954840.49.0.714955943422.issue4704@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the responses! > I don't think should go into 3.0.1 - they are a new feature > and not a bug fix. But if these changes don't go into 3.0.1, and the removal of cmp does, that means that pybench won't run on 3.0.1. It seems to me that we could make a strong case for this being a bugfix... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 15:18:06 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 22 Dec 2008 14:18:06 +0000 Subject: [issue4704] Update pybench for python 3.0 In-Reply-To: <1229954840.49.0.714955943422.issue4704@psf.upfronthosting.co.za> Message-ID: <494FA19C.9030407@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-22 15:07, Mark Dickinson wrote: > Mark Dickinson added the comment: > > Thanks for the responses! > >> I don't think should go into 3.0.1 - they are a new feature >> and not a bug fix. > > But if these changes don't go into 3.0.1, and the removal of cmp does, > that means that pybench won't run on 3.0.1. It seems to me that we could > make a strong case for this being a bugfix... ... or a good case for not removing cmp() from 3.0.1 :-) I have a feeling that people are mixing up the reasons for removal of the __cmp__ slot and the utility of the cmp() builtin. Those two should be treated as separate issues, IMHO. Anyway, like I said: the release manager should decide. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 15:25:56 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 22 Dec 2008 14:25:56 +0000 Subject: [issue1289118] timedelta multiply and divide by floating point Message-ID: <1229955956.66.0.606309331894.issue1289118@psf.upfronthosting.co.za> STINNER Victor added the comment: I like this idea, it's the opposite of the issue #2706. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 15:28:40 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 22 Dec 2008 14:28:40 +0000 Subject: [issue4291] Allow Division of datetime.timedelta Objects In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za> Message-ID: <1229956120.83.0.613177564196.issue4291@psf.upfronthosting.co.za> STINNER Victor added the comment: See related issues: #1289118 and #2706. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 15:42:41 2008 From: report at bugs.python.org (Scott Dial) Date: Mon, 22 Dec 2008 14:42:41 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1229956961.42.0.0518786304416.issue1706039@psf.upfronthosting.co.za> Scott Dial added the comment: I believe the original patch is overreaching. I believe the changes to fileobject.c should've been much simpler, just as the title describes (adding clearerr() just before performing reads on the FILE handles). I've attached a much simpler patch that I believe corrects the issue, but I don't have an OS X platform to try it on. ---------- nosy: +scottdial Added file: http://bugs.python.org/file12425/fileobject.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:01:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 15:01:35 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1229958095.87.0.754259018529.issue4718@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FYI, instead of trying to do exhaustive type checking in _check_type(), you can just rely on duck typing and catch the TypeError: >>> str(b"a", "utf-8") 'a' >>> str(bytearray(b"a"), "utf-8") 'a' >>> str(memoryview(b"a"), "utf-8") 'a' >>> str(1, "utf-8") Traceback (most recent call last): File "", line 1, in TypeError: coercing to str: need string or buffer, int found _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:02:19 2008 From: report at bugs.python.org (George) Date: Mon, 22 Dec 2008 15:02:19 +0000 Subject: [issue4721] pythonw.exe crash in GU application(PythonWX) In-Reply-To: <1229958139.91.0.337518597057.issue4721@psf.upfronthosting.co.za> Message-ID: <1229958139.91.0.337518597057.issue4721@psf.upfronthosting.co.za> New submission from George : I have Python 2.6.1 in Windows Vista. It happened in Python 2.6 and I hoped it would be fixed. I don't know what happenes in other versions. When I open a file containing a python program(".py"/".pyw" and even one compiled with py2exe) made by using the PythonWX GUI programming libraries it crashes immediately after the mouse hovers over the window created by the program(spesifically in the area inside it). It happenes both when the program is a ".py" file and a ".pyw" file or one compiled with py2exe. I get a message that the program stopped working. Shouldn'nt I get a message about wrong code? It doesn't crash in the Python Shell, but it has happened ,too, a few times. Do I do something wrong? Is there something I should know? The programs I use are not made by me(I can't yet make mine), but they are examples downloaded or copy-pasted. Here is one: import wx app = wx.PySimpleApp() frame = wx.Frame(None,-1,"Hello World") frame.Show(True) app.MainLoop() Please tell me what is wrong or what I should do. ---------- files: simple editor.pyw messages: 78189 nosy: george severity: normal status: open title: pythonw.exe crash in GU application(PythonWX) type: crash versions: Python 2.6 Added file: http://bugs.python.org/file12426/simple editor.pyw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:04:10 2008 From: report at bugs.python.org (George) Date: Mon, 22 Dec 2008 15:04:10 +0000 Subject: [issue4721] pythonw.exe crash in GUI application(PythonWX) In-Reply-To: <1229958139.91.0.337518597057.issue4721@psf.upfronthosting.co.za> Message-ID: <1229958250.04.0.141741194887.issue4721@psf.upfronthosting.co.za> Changes by George : ---------- title: pythonw.exe crash in GU application(PythonWX) -> pythonw.exe crash in GUI application(PythonWX) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:06:31 2008 From: report at bugs.python.org (Alex) Date: Mon, 22 Dec 2008 15:06:31 +0000 Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry values In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za> Message-ID: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za> New submission from Alex : == What steps will reproduce the problem? 1. Create registry key (let's assume it's located in HKEY_CURRENT_USER\TestKey); 2. Walk to it in "regedit"; 3. Right-click on "(Default)" and select "Modify binary data"; 4. Leave everything blank and press "OK"; 5. Go to Python and execute this: >>> import _winreg >>> _winreg.QueryValue(_winreg.HKEY_CURRENT_USER, 'TestKey') Traceback (most recent call last): File "", line 1, in SystemError: ..\Objects\stringobject.c:4271: bad argument to internal function == What is the expected output? What do you see instead? I expect either returning "''" or some ValueError indicating that source string is malformed. == What version of the product are you using? On what operating system? 1. Windows XP Professional SP2 English; 2. Tested on Python 2.5.2; 3. Tested on Python 2.6.1; 4. Tested on Stackless Python 2.5.2. == Please provide any additional information below. And yes, I know that this function is lame and everybody using it also is lame, but it's not really a reason to include buggy functions, right? ---------- components: Library (Lib), Windows messages: 78190 nosy: malicious.wizard severity: normal status: open title: _winreg.QueryValue fault while reading mangled registry values type: behavior versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:11:16 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 22 Dec 2008 15:11:16 +0000 Subject: [issue4721] pythonw.exe crash in GUI application(PythonWX) In-Reply-To: <1229958139.91.0.337518597057.issue4721@psf.upfronthosting.co.za> Message-ID: <1229958676.22.0.898419337474.issue4721@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please understand that the bug tracker is not a place to obtain help, but a place to provide help. You can help by analysing the source of the crash in a debugger, such as the one of Visual Studio. In any case, it seems that the crash is specific to wxPython, which is not part of the Python 2.6 distribution. Please report it to the authors of wxPython. Closing this report as 3rd-party. ---------- nosy: +loewis resolution: -> invalid status: open -> closed versions: +3rd party -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:23:50 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Mon, 22 Dec 2008 15:23:50 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1229959430.03.0.614310706267.issue4718@psf.upfronthosting.co.za> Phillip J. Eby added the comment: If you want to change to using bytes, you're going to have to take it to the Web-SIG and hash out a revision to PEP 333, which at the moment requires the use of strings, period. This has nothing to do with the desirability of bytes vs. strings; I am sure that if Python had bytes from day 1, bytes would've been the way to go with it. But simply changing the reference library is not the way to change the spec. In the meantime, as far as I'm aware, there are two other patches pending to address these issues, but I'm not in a position to assess their readiness/correctness since I have yet to even download Py3K. In principle, I approve their approaches, so if someone else can handle the code review, those fixes could in principle be put in without changing the PEP. But to put *this* patch in, the PEP would have to be changed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:37:47 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 15:37:47 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229959430.03.0.614310706267.issue4718@psf.upfronthosting.co.za> Message-ID: <1229960264.6263.47.camel@localhost> Antoine Pitrou added the comment: > If you want to change to using bytes, you're going to have to take it > to the Web-SIG and hash out a revision to PEP 333, which at the moment > requires the use of strings, period. What was called str in 2.x has become the bytes object in py3k. What was called unicode in 2.x has become str in py3k. (roughly) Given the meaning of the term "string" and its possible acceptions have dramatically changed between 2.x and py3k, how does this patch violate the PEP more than any other? Actually, the PEP says: HTTP does not directly support Unicode, and neither does this interface. All encoding/decoding must be handled by the application; all strings passed to or from the server must be standard Python *byte strings*, not Unicode objects. [emphasis mine] So, not accepting bytes in py3k is clearly a violation of the PEP! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:03:43 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Mon, 22 Dec 2008 16:03:43 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229958095.87.0.754259018529.issue4718@psf.upfronthosting.co.za> Message-ID: <494FBA5A.3020702@hlabs.spb.ru> Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > FYI, instead of trying to do exhaustive type checking in _check_type(), > you can just rely on duck typing and catch the TypeError: Good point! I'll update the patch soon. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:23:02 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 16:23:02 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1229962982.59.0.689487075482.issue4718@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: critical -> release blocker stage: -> patch review versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:27:43 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 16:27:43 +0000 Subject: [issue3795] wsgiref.simple_server fails to run demo_app In-Reply-To: <1220729895.68.0.892573521462.issue3795@psf.upfronthosting.co.za> Message-ID: <1229963263.29.0.525546505227.issue3795@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- superseder: -> wsgiref package totally broken _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:30:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 16:30:42 +0000 Subject: [issue3348] Cannot start wsgiref simple server in Py3k In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za> Message-ID: <1229963442.84.0.892582626322.issue3348@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There's a proper patch in #4718, marking this one in duplicate. ---------- resolution: -> duplicate status: open -> closed superseder: -> wsgiref package totally broken _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:36:14 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Mon, 22 Dec 2008 16:36:14 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229960264.6263.47.camel@localhost> Message-ID: <494FC1FA.6020200@hlabs.spb.ru> Dmitry Vasiliev added the comment: Antoine Pitrou wrote: >> If you want to change to using bytes, you're going to have to take it >> to the Web-SIG and hash out a revision to PEP 333, which at the moment >> requires the use of strings, period. > > What was called str in 2.x has become the bytes object in py3k. > What was called unicode in 2.x has become str in py3k. > (roughly) Agreed, moreover it's time for Python 3.0.1 and we need to decide - apply a patch or just remove wsgiref completely for now. Keep wsgiref just as nonworking piece of code is the worse solution which can made questionable all WSGI effort. Given that old str has been replaced by bytes in Python 3 I think the patch is a correct implementation of the PEP from the Python 3's point of view. To avoid confusion note about the meaning of the term *string* can be added to the PEP later. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:37:34 2008 From: report at bugs.python.org (=?utf-8?q?Klemens_H=C3=A4ckel?=) Date: Mon, 22 Dec 2008 16:37:34 +0000 Subject: [issue4723] os.path.basename error on directory names with numbers In-Reply-To: <1229963854.68.0.83545145541.issue4723@psf.upfronthosting.co.za> Message-ID: <1229963854.68.0.83545145541.issue4723@psf.upfronthosting.co.za> New submission from Klemens H?ckel : I am using python for some backup tasks, and recently i found a problem whe i have certain directory names. Probably the problem is only in windows, however i would like You to know. I verified the same behaviour in (WindowsXP, spanish, SP3) using Python 2.5.2 and also in 2.6.1 (installers from Python.org). In my case i have directory names, beginning with year/month numbers. Aparrently python is confusing something, so os.path.basename is not working: dd = 'C:\downloads\hacking\0812logcompress' >>> os.path.basename(dd) 'hacking\x00812logcompress' >>> dd = 'C:\downloads\hacking\logcompress' >>> os.path.basename(dd) 'logcompress' ---------- components: Windows messages: 78197 nosy: kle_py severity: normal status: open title: os.path.basename error on directory names with numbers type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:53:54 2008 From: report at bugs.python.org (Tim Golden) Date: Mon, 22 Dec 2008 16:53:54 +0000 Subject: [issue4723] os.path.basename error on directory names with numbers In-Reply-To: <1229963854.68.0.83545145541.issue4723@psf.upfronthosting.co.za> Message-ID: <1229964834.04.0.583771677407.issue4723@psf.upfronthosting.co.za> Tim Golden added the comment: You need to use raw strings or to use forward-slashes in your pathnames: r"c:\downloads\hacking\0812logcompress" or "c:/downloads/hacking/0812logcompress" The sequence \0 has a special meaning in strings, introducing an octal escape, I think. ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 18:20:19 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 17:20:19 +0000 Subject: [issue4724] setting f_exc_traceback aborts in debug builds In-Reply-To: <1229966419.5.0.164799717047.issue4724@psf.upfronthosting.co.za> Message-ID: <1229966419.5.0.164799717047.issue4724@psf.upfronthosting.co.za> New submission from Benjamin Peterson : $ ./python.exe Python 2.7a0 (trunk:67899, Dec 22 2008, 11:17:09) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys [36275 refs] >>> sys._getframe(0).f_exc_traceback = 23 Python/ceval.c:2720: failed assertion `tstate->frame->f_exc_traceback == NULL' Abort trap ---------- components: Interpreter Core messages: 78199 nosy: benjamin.peterson priority: high severity: normal status: open title: setting f_exc_traceback aborts in debug builds versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 18:52:02 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 22 Dec 2008 17:52:02 +0000 Subject: [issue4723] os.path.basename error on directory names with numbers In-Reply-To: <1229963854.68.0.83545145541.issue4723@psf.upfronthosting.co.za> Message-ID: <1229968322.05.0.296729639702.issue4723@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Tim is right; \0 is an octal escape (for the byte with the ordinal value 0). ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 18:52:06 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 17:52:06 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229968326.27.0.41517355688.issue4719@psf.upfronthosting.co.za> Benjamin Peterson added the comment: In fact, there is already a Py3k warning for sys.exc_clear(). I'm still not convinced that 2to3 should play a role. What should it do? Simply remove the call? I'm apprehensive about trying to guess the intention of the user. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 18:53:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2008 17:53:42 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229968422.26.0.714891114393.issue4719@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If this is already handled by the -3 flag then I agree it's not a bug. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 18:54:09 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 17:54:09 +0000 Subject: [issue4719] sys.exc_clear() not flagged in any way In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za> Message-ID: <1229968449.28.0.989736821701.issue4719@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 18:56:25 2008 From: report at bugs.python.org (rocky bernstein) Date: Mon, 22 Dec 2008 17:56:25 +0000 Subject: [issue4725] reporting file locations in egg (and other package) files In-Reply-To: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za> Message-ID: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za> New submission from rocky bernstein : When listing a traceback or showing stack frames or implementing a debugger (or a tool which wants to track the exact location of the source code), how is one supposed to detect a file located inside an egg or some other archive mechanism? There are a number of issues, I think. First, I think some sort of consistent naming convention would be helpful. Here's an example of the current situation. I have a file called tracer.py inside egg /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py and I get an exception inside of that. The traceback shows this: File "build/bdist.linux-i686/egg/tracer.py", line 216, in size The file information comes from frame.f_code.co_filename and its relation to a file is a bit nebulous since there is no file either in the filesystem with that path suffix nor a file in an with that name. (It's possible there was a file with that suffix at one time during the build of the egg.) So possibly this is a bug. Via the __loader__ key in the tracer module's __dict__ hash (a zipimporter object) there is a _files hash which has a key "tracer.py" with value "/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py". This seems to correspond to a file tracer.py in zip file: /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg Glomming the two parts together as one entity or one name is a bit weird and means that things that work on files will have do some parsing to figure out that this there is a member inside an archive (and egg here). PEP 302 has lots of interesting things in it such as a way to get the file source text, but it doesn't specify uniform file *names* of either the surrounding package/archive or the member inside that. So possibly this is an omission or something that should be added. Finally looking at linecache.py, the function update_cache() has a routine to do some sort of filename resolution consulting loaders using the API of PEP 302. Possibly the name resolution part (without reading file data) might be made callable by itself so that it returns a package/archive name and a package/archive member name. ---------- messages: 78203 nosy: rocky severity: normal status: open title: reporting file locations in egg (and other package) files type: behavior versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 19:03:19 2008 From: report at bugs.python.org (Guilherme Polo) Date: Mon, 22 Dec 2008 18:03:19 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229968999.63.0.981466603312.issue1524639@psf.upfronthosting.co.za> Guilherme Polo added the comment: I hope you are not too bored for me commenting on this again. So, I have re-though about this issue today and decided to solve it differently (and will include a patch here this time, don't worry about mentions to external repo this time). To solve the problem I replaced the tk.call method in the Tk so it can remove registered commands in the call in case it fails. The other problems reported in this issue are also solved by it, and others that weren't reported are too: Misc.selection_handle (just to name one, but there are others) could leave a undesired item in _tclCommands too. Another advantage of this solution is that extensions benefit from it, and they do not need to change their code (except if they are using a collection of internal functions, which they shouldn't, affected by this patch). Added file: http://bugs.python.org/file12427/keep_tclcommands_correct.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 19:24:20 2008 From: report at bugs.python.org (pw) Date: Mon, 22 Dec 2008 18:24:20 +0000 Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX In-Reply-To: <1190400129.03.0.21752289973.issue1187@psf.upfronthosting.co.za> Message-ID: <1229970260.77.0.813346243539.issue1187@psf.upfronthosting.co.za> pw added the comment: Stumbled on this bug a different way in 2.5.2. My code worked in 2.5, which included change 51793, but fails in 2.5.1 and beyond due to the reimplementation in 53294. Dustin's patch, applied by hand to 2.5.2, fixes things for me. ---------- nosy: +pw versions: +Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 19:26:24 2008 From: report at bugs.python.org (guyer) Date: Mon, 22 Dec 2008 18:26:24 +0000 Subject: [issue4726] doctest gets line numbers wrong due to quotes in comments In-Reply-To: <1229970384.34.0.779810047928.issue4726@psf.upfronthosting.co.za> Message-ID: <1229970384.34.0.779810047928.issue4726@psf.upfronthosting.co.za> New submission from guyer : My text editor places a comment block at the top of each source file with a block of information about the author, the project, license, etc. One (rather pointless) line of this block looks like # FILE: "somefile.py" The re in `_find_lineno()` misinterprets this line as the beginning of the docstring. I believe the attached patch maintains the spirit of the re, while avoiding this false positive. ---------- components: Tests files: doctest_find_lineno.diff keywords: patch messages: 78206 nosy: guyer severity: normal status: open title: doctest gets line numbers wrong due to quotes in comments versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file12428/doctest_find_lineno.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 19:36:35 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Mon, 22 Dec 2008 18:36:35 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1229970995.39.0.567591960539.issue4718@psf.upfronthosting.co.za> Dmitry Vasiliev added the comment: New version of the patch: - Now only Unicode strings are allowed as status and headers because allowing bytes leads to big changes in wsgiref.validate and wsgiref.handlers; ---------- versions: -Python 3.1 Added file: http://bugs.python.org/file12429/wsgiref2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 19:54:08 2008 From: report at bugs.python.org (Guilherme Polo) Date: Mon, 22 Dec 2008 18:54:08 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229972048.28.0.205433901421.issue1524639@psf.upfronthosting.co.za> Changes by Guilherme Polo : Removed file: http://bugs.python.org/file12427/keep_tclcommands_correct.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 19:54:29 2008 From: report at bugs.python.org (Guilherme Polo) Date: Mon, 22 Dec 2008 18:54:29 +0000 Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks Message-ID: <1229972069.03.0.416337248638.issue1524639@psf.upfronthosting.co.za> Changes by Guilherme Polo : Added file: http://bugs.python.org/file12430/keep_tclcommands_correct.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 21:03:07 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 20:03:07 +0000 Subject: [issue4717] execfile conversion is not correct In-Reply-To: <1229945098.56.0.809169461336.issue4717@psf.upfronthosting.co.za> Message-ID: <1229976187.29.0.206766161948.issue4717@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r67900. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 21:53:20 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 20:53:20 +0000 Subject: [issue4720] Extension function optional argument specification | causes RuntimeError In-Reply-To: <1229950163.26.0.0772490400351.issue4720@psf.upfronthosting.co.za> Message-ID: <1229979200.99.0.131686301943.issue4720@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67905. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 22:16:30 2008 From: report at bugs.python.org (Winfried Plappert) Date: Mon, 22 Dec 2008 21:16:30 +0000 Subject: [issue4169] library/turtle.rst does not format properly in PDF mode In-Reply-To: <1224662867.9.0.0428544955295.issue4169@psf.upfronthosting.co.za> Message-ID: <1229980590.93.0.734798906865.issue4169@psf.upfronthosting.co.za> Winfried Plappert added the comment: When looking at the PDF documentation for Python 2.6.1, the issue4169 is gone away. What has changed? I think we can close 4169 now. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 22:25:23 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 21:25:23 +0000 Subject: [issue4169] library/turtle.rst does not format properly in PDF mode In-Reply-To: <1224662867.9.0.0428544955295.issue4169@psf.upfronthosting.co.za> Message-ID: <1229981123.02.0.116808596082.issue4169@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 22:27:42 2008 From: report at bugs.python.org (Winfried Plappert) Date: Mon, 22 Dec 2008 21:27:42 +0000 Subject: [issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost In-Reply-To: <1224604021.37.0.924796663652.issue4162@psf.upfronthosting.co.za> Message-ID: <1229981262.01.0.870367922974.issue4162@psf.upfronthosting.co.za> Winfried Plappert added the comment: Changes to Sphinx fixed issue4162 for Python version 2.6.1. This issue can be closed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 22:28:24 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 21:28:24 +0000 Subject: [issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost In-Reply-To: <1224604021.37.0.924796663652.issue4162@psf.upfronthosting.co.za> Message-ID: <1229981304.53.0.275605192657.issue4162@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 22:36:02 2008 From: report at bugs.python.org (Winfried Plappert) Date: Mon, 22 Dec 2008 21:36:02 +0000 Subject: [issue4173] PDF documentation: long verbatim lines are cut off at right hand side In-Reply-To: <1224684717.3.0.110027961744.issue4173@psf.upfronthosting.co.za> Message-ID: <1229981762.92.0.0262848374894.issue4173@psf.upfronthosting.co.za> Winfried Plappert added the comment: see also issue4160. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 22:36:39 2008 From: report at bugs.python.org (Winfried Plappert) Date: Mon, 22 Dec 2008 21:36:39 +0000 Subject: [issue4160] library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side In-Reply-To: <1224601594.18.0.145893129918.issue4160@psf.upfronthosting.co.za> Message-ID: <1229981799.1.0.347163466531.issue4160@psf.upfronthosting.co.za> Winfried Plappert added the comment: see also issue4173, might be the same root cause. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 23:32:54 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Mon, 22 Dec 2008 22:32:54 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229960264.6263.47.camel@localhost> Message-ID: <20081222223249.6FF453A405E@sparrow.telecommunity.com> Phillip J. Eby added the comment: At 03:37 PM 12/22/2008 +0000, Antoine Pitrou wrote: >So, not accepting bytes in py3k is clearly a violation of the PEP! On the contrary. Please read the two paragraphs *after* the one you quoted. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 23:39:21 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Mon, 22 Dec 2008 22:39:21 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1229985561.27.0.860855502529.issue4718@psf.upfronthosting.co.za> Phillip J. Eby added the comment: To be quite clear: this change requires discussion on the Web-SIG and an appropriate revision of the PEP. Ideally, the patch should include the necessary PEP revision. The Web-SIG discussion regarding a switch to bytes should also take into consideration the effects of running 2to3 on existing WSGI applications and/or servers. Will their code be converted to use bytes, or Unicode? The previous choice to use Unicode was based on source compatibility across Python implementations, so this shouldn't be thrown out on the basis of simple expediency. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 23:53:15 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 22 Dec 2008 22:53:15 +0000 Subject: [issue3959] Add Google's ipaddr.py to the stdlib In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za> Message-ID: <1229986395.39.0.331721508677.issue3959@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Now that 2.6 and 3.0 are out of the way, how should we move forward? Will a PEP be required? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 00:35:09 2008 From: report at bugs.python.org (=?utf-8?q?Klemens_H=C3=A4ckel?=) Date: Mon, 22 Dec 2008 23:35:09 +0000 Subject: [issue4723] os.path.basename error on directory names with numbers In-Reply-To: <1229963854.68.0.83545145541.issue4723@psf.upfronthosting.co.za> Message-ID: <1229988909.78.0.500619780423.issue4723@psf.upfronthosting.co.za> Klemens H?ckel added the comment: Of course my example was not that trivial, since i do sort of directory-walking, and i get the value passed over. And in Windows it is with backslash! Ok, i will check my code, wherever i use os.path.basename and change it to process as raw string. Thank You _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 00:58:02 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 22 Dec 2008 23:58:02 +0000 Subject: [issue3959] Add Google's ipaddr.py to the stdlib In-Reply-To: <1229986395.39.0.331721508677.issue3959@psf.upfronthosting.co.za> Message-ID: <49502986.3050609@v.loewis.de> Martin v. L?wis added the comment: > Now that 2.6 and 3.0 are out of the way, how should we move forward? I think some committer needs to take charge and work with the authors on merging the code. If pmoody wants commit access, that should be set up, and he should add it himself in a commit-after-review manner (with an actual patch, including documentation and tests). If he doesn't want to do the integration, some committer needs to volunteer - I personally won't (lack of time). In any case, we would need a copyright form signed, unless Guido can confirm that the code is covered by some agreement between Google and the PSF. > Will a PEP be required? I doubt that; a quick announcement to python-dev might be sufficient (in general, a PEP should only be done if dissent is likely). It seems that Victor didn't actually disagree to integrating this package; we should somehow encourage IPy users to review the code and comment on the (possibly lack of) functionality. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 01:01:42 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Dec 2008 00:01:42 +0000 Subject: [issue4723] os.path.basename error on directory names with numbers In-Reply-To: <1229988909.78.0.500619780423.issue4723@psf.upfronthosting.co.za> Message-ID: <49502A63.5010008@v.loewis.de> Martin v. L?wis added the comment: > Of course my example was not that trivial, since i do sort of > directory-walking, and i get the value passed over. And in Windows it is > with backslash! Not necessarily. Windows supports forward slashes as path separators just as well. > Ok, i will check my code, wherever i use os.path.basename and change it > to process as raw string. You can consider avoiding the path separator by using os.path.join all the time. There might still be places where you need to provide absolute file names as literals in your source code, but those should be few. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 01:16:03 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Dec 2008 00:16:03 +0000 Subject: [issue4725] reporting file locations in egg (and other package) files In-Reply-To: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za> Message-ID: <1229991363.11.0.589580979472.issue4725@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If this message is about multiple issues (as the second paragraph suggests), they should be reported separately. As it stands, this is too much text for me to consider, and it might be too much for other readers as well. When you split it up, please consider whether the things are bugs or wishes, and whether they apply to Python proper, or some other library (e.g. setuptools - eggs are not part of Python). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 03:25:40 2008 From: report at bugs.python.org (rocky bernstein) Date: Tue, 23 Dec 2008 02:25:40 +0000 Subject: [issue4725] reporting file locations in egg (and other package) files In-Reply-To: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za> Message-ID: <1229999140.62.0.92680179898.issue4725@psf.upfronthosting.co.za> rocky bernstein added the comment: > > Martin v. L??wis added the comment: > > If this message is about multiple issues (as the second paragraph > suggests), they should be reported separately. As it stands, this is too > much text for me to consider, and it might be too much for other readers > as well. Fair enough. So let's start with I guess the most important thing. PEP 302 describes an importer protocol. Given that, I don't understand how I can reliably get full (package) information about where the source code resides from a stack frame or code object. For code that comes from packages like eggs (but not necessarily restricted to eggs as there may be other packaging mechanisms), the information would contain the package file (e.g. /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg), a member inside that (e.g. tracer.py), and possibly loader/packaging information (e.g. zipimporter). For a specific mechanism like zipimporter, no doubt one can hack something based on how the package mechanism is currently implemented. But given there is an API for import hooks that package mechanisms currently adhere to, shouldn't there also be some sort of API for untangling what has gone on? A use case here is in a stack trace or a debugger where an error occured. For example does this come from an egg? And if so, which one? Perhaps I have missed something in PEP 302, or perhaps this is defined elsewhere. Please elucidate. > When you split it up, please consider whether the things are > bugs or wishes, and whether they apply to Python proper, or some other > library (e.g. setuptools - eggs are not part of Python). Ok. I'll probably add one more "bug" report for now see where things go. Based on the outcome of these queries, I'll possibly add more. The problem I have with splitting things up too soon is that I'm not sure where the problem lies. As stated above, I think the crux is that given that there are now package mechanisms that bundle source code into a file, the notion of a "file" location should be adjusted to include the package and/or importer. If it turns out that there already is this notion, then it could be that certain implementations aren't aware of it and/or don't adhere to it. > > ---------- > nosy: +loewis > > _______________________________________ > Python tracker > > _______________________________________ > > _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 03:35:03 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Tue, 23 Dec 2008 02:35:03 +0000 Subject: [issue4727] pickle/copyreg doesn't support keyword only arguments in __new__ In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za> Message-ID: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za> New submission from Erick Tryzelaar : According to both of these bugs: http://bugs.python.org/issue1398 http://bugs.python.org/issue4331 pickle can't pickle functools.partial objects. It looks the underlying reason is that objects that pickle can't handle objects with __new__ and keyword only arguments. To support this, would this require a new pickle protocol and a __getnewfullargs__ that returns a tuple and dict? ---------- components: Library (Lib) messages: 78222 nosy: erickt severity: normal status: open title: pickle/copyreg doesn't support keyword only arguments in __new__ type: feature request versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 04:31:42 2008 From: report at bugs.python.org (Senthil) Date: Tue, 23 Dec 2008 03:31:42 +0000 Subject: [issue1025540] urllib2 http auth Message-ID: <1230003102.65.0.154182846488.issue1025540@psf.upfronthosting.co.za> Senthil added the comment: This issue makes a request to implement, plain-text inurl password authentication like "https://user:password at host:port/ for HTTP Basic Authentication. " for urllib2. As per rfc3986, this is strongly discouraged and is deprecated. See the section: 3.2.1. User Information Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used. Also, this was reported on 2004-09-10! We do not have any other similar requests inline. AFAIK, current urllib2 will authenticate and fetch the documents with HTTP Basic authentication when password is passed along in the url like the case specifies. I do not what was the case in 2004. My conclusion for this request is to Close it as either "Invalid" or "Wont Fix". ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 04:59:56 2008 From: report at bugs.python.org (Cournapeau David) Date: Tue, 23 Dec 2008 03:59:56 +0000 Subject: [issue4728] Endianness and universal builds problems In-Reply-To: <1230004796.26.0.433339643882.issue4728@psf.upfronthosting.co.za> Message-ID: <1230004796.26.0.433339643882.issue4728@psf.upfronthosting.co.za> New submission from Cournapeau David : I had some problems with python and universal builds related to the WORDS_BIGENDIAN macro. Because universal builds are built in one pass (one configure), the AC_C_ENDIAN cannot be used reliably. Example: int main() { #ifdef WORDS_BIGENDIAN printf("Big endian macro defined\n"); #else printf("No big endian macro defined\n"); #endif return 0; } If I build this against python 2.5, it prints no big endian macro (I have an intel CPU), as expected. But with python 2.6.0 (official binary from python.org), I get Big endian macro defined. ---------- messages: 78224 nosy: cdavid severity: normal status: open title: Endianness and universal builds problems _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 06:49:48 2008 From: report at bugs.python.org (Senthil) Date: Tue, 23 Dec 2008 05:49:48 +0000 Subject: [issue4729] Documentation under 'pass' statement talks about exception very early. In-Reply-To: <1230011388.24.0.107578151704.issue4729@psf.upfronthosting.co.za> Message-ID: <1230011388.24.0.107578151704.issue4729@psf.upfronthosting.co.za> New submission from Senthil : This is a new change in the documentation. Tutorial -> More Control Flow Tools -> pass Statements There is a new section which says: "However, as pass is silently ignored, a better choice may be to raise a NotImplementedError exception:""" While what the section says is correct, but its placement in the documentation is inappropriate. The tutorial has not yet introduced the reader to function and Exceptions, and this portion has squeezed its way in between. I feel, this needs to be rearranged. Georg, what is your thought? ---------- assignee: georg.brandl components: Documentation messages: 78225 nosy: georg.brandl, orsenthil severity: normal status: open title: Documentation under 'pass' statement talks about exception very early. type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 07:40:36 2008 From: report at bugs.python.org (Brian) Date: Tue, 23 Dec 2008 06:40:36 +0000 Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za> Message-ID: <1230014436.88.0.00602843005324.issue4660@psf.upfronthosting.co.za> Brian added the comment: Here are a few stabs at how this might be addressed. 1) As originally suggested. Allow task_done() to block waiting to acquire _unfinished_tasks. This will allow the put() process to resume, release() _unfinished_tasks at which point task_done() will unblock. No harm, no foul but you do lose some error checking (and maybe some performance?) 2) One can't protect JoinableQueue.put() by simply acquiring _cond before calling Queue.put(). Fixed size queues will block if the queue is full, causing deadlock when task_done() can't acquire _cond. The most obvious solution would seem to be reimplementing JoinableQueue.put() (not simply calling Queue.put()) and then inserting self._unfinished_tasks.release() into a protected portion. Perhaps: def put(self, obj, block=True, timeout=None): assert not self._closed if not self._sem.acquire(block, timeout): raise Full self._notempty.acquire() self._cond.acquire() try: if self._thread is None: self._start_thread() self._buffer.append(obj) self._unfinished_tasks.release() self._notempty.notify() finally: self._cond.release() self._notempty.release() We may be able to get away with not acquiring _cond as _notempty would provide some protection. However its relationship to get() isn't entirely clear to me so I am not sure if this would be sufficient. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 09:39:53 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Dec 2008 08:39:53 +0000 Subject: [issue4725] reporting file locations in egg (and other package) files In-Reply-To: <1229999140.62.0.92680179898.issue4725@psf.upfronthosting.co.za> Message-ID: <4950A3D5.7000906@v.loewis.de> Martin v. L?wis added the comment: > A use case here is in a stack trace or a debugger where an error > occured. For example does this come from an egg? And if so, which one? > > Perhaps I have missed something in PEP 302, or perhaps this is defined > elsewhere. Please elucidate. Please understand that the bug tracker is not a place to ask questions, or get help. If you make a bug report, *ALWAYS* follow this pattern: 1. this is what I did 2. this is what happened 3. this is what I would have expected instead If you want to get help in doing something that you don't know how to do, or need elucidation, use python-list at python.org. If you are proposing a new feature, and want to discuss the design of it, use python-dev at python.org; you might be told to write a PEP if the feature is more complex. I'm going to close this report as invalid. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 09:40:35 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Dec 2008 08:40:35 +0000 Subject: [issue4725] reporting file locations in egg (and other package) files In-Reply-To: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za> Message-ID: <1230021635.39.0.700600962452.issue4725@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 10:24:40 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Dec 2008 09:24:40 +0000 Subject: [issue4728] Endianness and universal builds problems In-Reply-To: <1230004796.26.0.433339643882.issue4728@psf.upfronthosting.co.za> Message-ID: <1230024280.09.0.0167644634336.issue4728@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is related to issue4060. Ronald, what is the status of that? The only reason why BIGENDIAN could be defined in the official binaries is that the build was created on a PPC system. Benjamin, is that the case? ---------- nosy: +benjamin.peterson, loewis, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 12:15:00 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Tue, 23 Dec 2008 11:15:00 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230030900.39.0.287202892359.issue4718@psf.upfronthosting.co.za> Dmitry Vasiliev added the comment: OK, I've attached PEP-333 compatible fixes for wsgiref. I think there is only one problem remains: - wsgiref expects io.BytesIO as input and output streams because of http.server module. I didn't find any restrictions on data returned by read() method of the "wsgi.input" stream in the PEP. Maybe I've missed some details? Added file: http://bugs.python.org/file12431/wsgiref_pep333.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 13:30:46 2008 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 23 Dec 2008 12:30:46 +0000 Subject: [issue4730] cPickle corrupts high-unicode strings In-Reply-To: <1230035446.04.0.56766649246.issue4730@psf.upfronthosting.co.za> Message-ID: <1230035446.04.0.56766649246.issue4730@psf.upfronthosting.co.za> New submission from Nathaniel Smith : cPickle.dump by default does not properly encode unicode characters outside the BMP -- it throws away the high bits: >>> cPickle.loads(cPickle.dumps(u"\U00012345")) u'\u2345' The problem is in dump, not load: >>> pickle.dumps(u"\U00012345") # works 'V\\U00012345\np0\n.' >>> cPickle.dumps(u"\U00012345") # no! 'V\\u2345\n.' It does work correctly when using a more modern pickling protocol: >>> cPickle.loads(cPickle.dumps(u"\U00012345", 1)) u'\U00012345' >>> cPickle.loads(cPickle.dumps(u"\U00012345", 2)) u'\U00012345' But this is not much comfort for users whose data has been corrupted because they went with the defaults. (Fortunately in my application I knew that all my characters were in the supplementary plane, so I could repair the data after the fact, but...) Above tests are with 2.5.2, but from checking the source, the bug is obviously still present in 2.6.1: cPickle.c:modified_EncodeRawUnicodeEscape has no code to handle 32-bit unicode values. OTOH, it does look like someone noticed the problem and fixed it for 3.0; _pickle.c:raw_unicode_escape handles such characters fine. Guess they just forgot to backport the fixes... but the code is there, and can probably just be copy-pasted back to 2.6. ---------- components: Library (Lib) messages: 78230 nosy: njs severity: normal status: open title: cPickle corrupts high-unicode strings versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 13:55:25 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 23 Dec 2008 12:55:25 +0000 Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86 In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za> Message-ID: <1230036925.52.0.216025598739.issue4575@psf.upfronthosting.co.za> Mark Dickinson added the comment: Final patch. Skip, could you please give this one a try, and then with any luck this can be fixed for 3.0.1. (Sorry for creating more work; this should be the last time.) I've added a configure test that detects x87 FPU usage, via the double rounding issue associated with the x87. If x87 is detected then _Py_force_double is used via a macro Py_FORCE_DOUBLE; otherwise, Py_FORCE_DOUBLE does nothing. When you configure on a machine that uses x87, you should see: checking for x87-style double rounding... yes in the configure output. Added file: http://bugs.python.org/file12432/force_to_memory5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 13:57:20 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Dec 2008 12:57:20 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230037040.14.0.84505669799.issue4718@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Please read the two paragraphs *after* the one you quoted. I don't see anything forbidding bytes objects in those two paragraphs. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 14:08:44 2008 From: report at bugs.python.org (Kuba Wieczorek) Date: Tue, 23 Dec 2008 13:08:44 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1230037724.47.0.389255366997.issue4710@psf.upfronthosting.co.za> Kuba Wieczorek added the comment: Here is a revised version of the patch with directories support for write(). It works like UNIX zip program so if a directory path is passed to the function, it stores only the directory itself (without the contents). This time without tests as well because I don't want to mess up with them until I finish my patch completely. Added file: http://bugs.python.org/file12433/zipfile_dirs_support.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 14:23:29 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 23 Dec 2008 13:23:29 +0000 Subject: [issue4728] Endianness and universal builds problems In-Reply-To: <1230004796.26.0.433339643882.issue4728@psf.upfronthosting.co.za> Message-ID: <1230038609.42.0.375261709095.issue4728@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes, I made the build on a PPC machine. I'm no expert on this, but maybe we should just get rid of the configure check and use the __LITTLE_ENDIAN__ and __BIG_ENDIAN__ macros. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 14:43:10 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Dec 2008 13:43:10 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230030900.39.0.287202892359.issue4718@psf.upfronthosting.co.za> Message-ID: <1230039788.12104.20.camel@localhost> Antoine Pitrou added the comment: Le mardi 23 d?cembre 2008 ? 11:15 +0000, Dmitry Vasiliev a ?crit : > Dmitry Vasiliev added the comment: > > OK, I've attached PEP-333 compatible fixes for wsgiref. I may be mistaken, but it seems that your patch forces iso-8859-1 encoding of http bodies. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:07:41 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Tue, 23 Dec 2008 14:07:41 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230039788.12104.20.camel@localhost> Message-ID: <4950F0A8.2010304@hlabs.spb.ru> Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > Le mardi 23 d?cembre 2008 ? 11:15 +0000, Dmitry Vasiliev a ?crit : >> OK, I've attached PEP-333 compatible fixes for wsgiref. > > I may be mistaken, but it seems that your patch forces iso-8859-1 > encoding of http bodies. No, just as PEP said str used as a container for binary data. For example to return UTF-8 encoded data you can use the following code: def app(environ, start_response): ... return [data.encode("utf-8").decode("iso-8859-1")] I don't like it but I guess it's strictly follow the PEP (actually I didn't notice this sections before): """ On Python platforms where the str or StringType type is in fact Unicode-based (e.g. Jython, IronPython, Python 3000, etc.), all "strings" referred to in this specification must contain only code points representable in ISO-8859-1 encoding (\u0000 through \u00FF, inclusive). It is a fatal error for an application to supply strings containing any other Unicode character or code point. Similarly, servers and gateways must not supply strings to an application containing any other Unicode characters. Again, all strings referred to in this specification must be of type str or StringType, and must not be of type unicode or UnicodeType. And, even if a given platform allows for more than 8 bits per character in str/StringType objects, only the lower 8 bits may be used, for any value referred to in this specification as a "string". """ We definitely need to use bytes in the future but it requires PEP update and some migration guide. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:26:52 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Dec 2008 14:26:52 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <4950F0A8.2010304@hlabs.spb.ru> Message-ID: <1230042406.12104.61.camel@localhost> Antoine Pitrou added the comment: > No, just as PEP said str used as a container for binary data. This is clearly the wrong thing to do. The only (immutable) string-like object adequate for binary data in py3k is bytes, not str. I understand the desire to stick to the PEP, but the PEP was devised even before the first py3k alphas, and it clearly wasn't written with py3k in mind. For example the following sentence becomes nonsensical: Again, all strings referred to in this specification must be of type str or StringType, and must not be of type unicode or UnicodeType. since "str" objects *are* of type UnicodeType in py3k (and the C API is still named PyUnicode_*)... When a legal text becomes nonsensical wrt. reality, one has to adapt his interpretation of the text to reality, not adapt reality to match the nonsense. In other words, wsgiref should accept/expose HTTP bodies as bytes, not str. Confusing binary data with iso-8859-1 text is the kind of mess py3k was designed to avoid. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:33:26 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Dec 2008 14:33:26 +0000 Subject: [issue4730] cPickle corrupts high-unicode strings In-Reply-To: <1230035446.04.0.56766649246.issue4730@psf.upfronthosting.co.za> Message-ID: <1230042806.51.0.00735564916576.issue4730@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 16:07:50 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Dec 2008 15:07:50 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1230044870.76.0.945739325617.issue1706039@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have now reverted the patch in r67914. I won't reject the patch because of Scott's alternative, but leave it open for review. Since Scott's patch is not approved yet, this is not a release blocker anymore. ---------- assignee: loewis -> priority: release blocker -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 16:47:24 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 23 Dec 2008 15:47:24 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1230047244.88.0.294584385404.issue1706039@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I've combined Scott's patch with John's (?) test case in issue1706039.diff. Confirmed that the patch fixes the issue on Mac OS X 10.5.6 (Intel). Added file: http://bugs.python.org/file12434/issue1706039.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 17:03:25 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 23 Dec 2008 16:03:25 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1230048205.57.0.419585087943.issue1706039@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Maybe not a problem, but an inconsistency: in Py_UniversalNewlineFgets clearerr is added inside univ_newline conditional and then again before the loop over characters, but in Py_UniversalNewlineFread it is added only once before "if (!f->f_univ_newline)". I am not sure which approach is right, but I don't think there is a reason for the two functions to be different. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 17:08:06 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Tue, 23 Dec 2008 16:08:06 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230042406.12104.61.camel@localhost> Message-ID: <20081223160802.7D8653A409D@sparrow.telecommunity.com> Phillip J. Eby added the comment: Antoine, you have three choices here: 1. Follow the PEP, 2. Take it to the Web-SIG and get the appropriate discussion, consensus, and PEP revision, or 3. Drop wsgiref from the current release of Py3K until #2 can be done. Which would you prefer? Please note that your arguments regarding what revision should take place are irrelevant here; the correct forum for that discussion is the Web-SIG. Personally, I think they are valid arguments; WSGI simply did not have the benefit of having a sane (and standard!) "bytes" type available, and were we writing the spec today, I would absolutely have specified it in a bytes-oriented way, and treated older Pythons as the special case. However, we have to take into consideration how applications will be *migrated* to Py3K. I am not an expert in this, nor do I personally have huge volumes of code that will be migrated. Therefore, the correct forum for discussing migration impact and how best to write the spec is the Web-SIG. Making the change to bytes is not something to be undertaken on a whim: the spec must include how to handle inadvertent mixing of bytes and unicode, in order to allow unambiguous error handling and migration support. It will not be solved by the fiat of one individual: certainly not by you or I. And it has absolutely nothing to do with what is "right" in the technical sense, because it is not a technical problem. A specification is a social construct, not a technical one, so changing wsgiref by itself solves nothing. And that's why those three choices are the only available options, so far as I am aware. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 18:05:13 2008 From: report at bugs.python.org (John Smith) Date: Tue, 23 Dec 2008 17:05:13 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1230051913.21.0.00493578602709.issue1706039@psf.upfronthosting.co.za> John Smith added the comment: Sorry for inconvenience caused with the patch. I should've got more reviews before asking it checked in. I verified eof2.diff-applied-python gets "Bus error" and Scott Dial's fileobject.diff fixes this. (Test was on 9.6.0 Darwin Kernel Version 9.6.0) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 18:09:08 2008 From: report at bugs.python.org (Kuba Wieczorek) Date: Tue, 23 Dec 2008 17:09:08 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1230052148.27.0.0314907957641.issue4710@psf.upfronthosting.co.za> Changes by Kuba Wieczorek : Removed file: http://bugs.python.org/file12433/zipfile_dirs_support.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 18:10:32 2008 From: report at bugs.python.org (Kuba Wieczorek) Date: Tue, 23 Dec 2008 17:10:32 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1230052232.07.0.474758809455.issue4710@psf.upfronthosting.co.za> Changes by Kuba Wieczorek : Added file: http://bugs.python.org/file12435/zipfile_dirs_support.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 18:13:23 2008 From: report at bugs.python.org (Scott Dial) Date: Tue, 23 Dec 2008 17:13:23 +0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1230052403.71.0.543013176831.issue1706039@psf.upfronthosting.co.za> Scott Dial added the comment: They differ because in Py_UniversalNewlineFgets() there is a call to FLOCKFILE(), and it seemed appropriate to ensure that clearerr() was called after locking the FILE stream. I certainly pondered over whether it made a difference to do it before or after, and it would seem to me that if we are bothering to lock the FILE stream then we would care to ensure that the first GETC() after locking reaps the benefit of having called clearerr(). In the cases that we fall into fread and fgets, we may actually need to be doing: FLOCKFILE(stream) clearerr(stream); result = fgets(buf, n, stream); FUNLOCKFILE(stream); return result; One nitpick is that the testcase was appended to the StdoutTests class instead of OtherFileTests class, which would seem more appropriate. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 19:14:40 2008 From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Tue, 23 Dec 2008 18:14:40 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za> Message-ID: <20081223181436.GA20790@chistera.yi.org> Adeodato Sim? added the comment: Hello, I see that something akin to my proposed patch was applied, but I think the order of the arguments to shutil.copymode was reversed in the process. This function takes (src, dst) as arguments, and we want permissions to flow backup -> newfile, and not the the other way around. Thanks already. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 19:21:36 2008 From: report at bugs.python.org (Mike Coleman) Date: Tue, 23 Dec 2008 18:21:36 +0000 Subject: [issue4731] suggest change to "Failed to find the necessary bits to build these modules" message In-Reply-To: <1230056496.59.0.297027994957.issue4731@psf.upfronthosting.co.za> Message-ID: <1230056496.59.0.297027994957.issue4731@psf.upfronthosting.co.za> New submission from Mike Coleman : I was thrown by the "Failed to find the necessary bits to build these modules" message at the end of newer Python builds, and thought that this indicated that the Python executable itself was not built. That's arguably stupidity on my part, but I wonder if others will not trip on this, too. Would it be possible to change this wording slightly, to something like Python built, but failed to find the necessary bits to build these modules ? ---------- components: Build messages: 78245 nosy: mkc severity: normal status: open title: suggest change to "Failed to find the necessary bits to build these modules" message type: feature request versions: Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 19:54:58 2008 From: report at bugs.python.org (Matteo Bertini) Date: Tue, 23 Dec 2008 18:54:58 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1230058498.44.0.725244209731.issue1068268@psf.upfronthosting.co.za> Matteo Bertini added the comment: Please have a look at the proposed patch: http://bugs.python.org/file11511/subprocess-eintr-safety-25maint- r65475.patch the list is more or less the patch itself. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 20:04:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Dec 2008 19:04:52 +0000 Subject: [issue4728] Endianness and universal builds problems In-Reply-To: <1230038609.42.0.375261709095.issue4728@psf.upfronthosting.co.za> Message-ID: <49513651.5090403@v.loewis.de> Martin v. L?wis added the comment: > Yes, I made the build on a PPC machine. Hmm. Ronald's instructions say that the build machine must be x86 for the build to work. I don't know what other consequences using PPC would have; I recommend that we follow these instructions until we understand them enough to change them. > I'm no expert on this, but maybe > we should just get rid of the configure check and use the > __LITTLE_ENDIAN__ and __BIG_ENDIAN__ macros. That won't work, as not all compilers define these macros. The 2.5 approach works fine (use the macros on OSX, and use the configure test elsewhere). Unfortunately, that support got removed in r63955. The patch in issue4060 looks fine; I'm unsure why it hasn't been applied yet. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 20:12:34 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 23 Dec 2008 19:12:34 +0000 Subject: [issue4602] 2to3 drops executable bit with --write In-Reply-To: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za> Message-ID: <1230059554.16.0.352568801369.issue4602@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for pointing that out! Fixed in r67919. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 21:12:31 2008 From: report at bugs.python.org (Andrew Gillis) Date: Tue, 23 Dec 2008 20:12:31 +0000 Subject: [issue4732] Object allocation stress leads to segfault on RHEL In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> Message-ID: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> New submission from Andrew Gillis : Allocating large numbers of strings objects has been causing Python to segfault on RHEL. Originally detected when sending large data structures over XMLRPC, but also happens when appending large numbers of small strings to a list and calling join in the list. -- Crash is always a segmentation fault when accessing the free list to allocate a python object (obmalloc.c) or an invalid pointer when accessing a string object during a join operation (stringobject.c) -- Happens on RHEL with latest updates and no modified RPMs. -- Also happens with Python built from source on RHEL machine. -- Crash happens on RHEL machines running on different hardware. -- Reproducible with Python 2.4, 2.5, 2.6 and RHEL 5.1 and 5.2. -- Problem not seed on FreeBSD 6.2 or 7.0. Attached to the bug report is a script that is capable of recreating the problem on various RHEL and Python versions. If running three instances of the script, usually one of them will segfault within 30 minutes. Below is a backtrace from the crash. This is in a call to join(), concatenating a very long sequence of strings. While iterating over the sequence of string objects to get the memory needed, one of the string objects appears to be located in invalid memory, resulting in segfault. #0 string_join (self=0xb7ee3098, orig=0xb08696c) at Objects/stringobject.c:1776 #1 0x008d3749 in PyEval_EvalFrameEx (f=0xb29499c, throwflag=0) at Python/ceval.c:3561 #2 0x008d4922 in PyEval_EvalCodeEx (co=0xb7c690b0, globals=0xb7edcdfc, locals=0x0, args=0x9dc29dc, argcount=2, kws=0x9dc29e4, kwcount=0, defs=0xb7c6cb78, defcount=1, closure=0x0) at Python/ceval.c:2836 #3 0x008d284c in PyEval_EvalFrameEx (f=0x9dc2884, throwflag=0) at Python/ceval.c:3669 #4 0x008d32bd in PyEval_EvalFrameEx (f=0xaef0414, throwflag=0) at Python/ceval.c:3659 #5 0x008d4922 in PyEval_EvalCodeEx (co=0xa2f2920, globals=0xa2d90b4, locals=0x0, args=0xab29710, argcount=1, kws=0xab29714, kwcount=3, defs=0xa2f3420, defcount=4, closure=0x0) at Python/ceval.c:2836 #6 0x008d284c in PyEval_EvalFrameEx (f=0xab295ac, throwflag=0) at Python/ceval.c:3669 #7 0x008d32bd in PyEval_EvalFrameEx (f=0xa936f614, throwflag=0) at Python/ceval.c:3659 #8 0x008d4922 in PyEval_EvalCodeEx (co=0x8f1b218, globals=0x8f1546c, locals=0x0, args=0xb347338, argcount=1, kws=0xb34733c, kwcount=0, defs=0x8f17c98, defcount=1, closure=0x0) at Python/ceval.c:2836 #9 0x008d284c in PyEval_EvalFrameEx (f=0xb3471ec, throwflag=0) at Python/ceval.c:3669 #10 0x008d32bd in PyEval_EvalFrameEx (f=0xaa322eac, throwflag=0) at Python/ceval.c:3659 #11 0x008d32bd in PyEval_EvalFrameEx (f=0xad9c8b4, throwflag=0) at Python/ceval.c:3659 #12 0x008d32bd in PyEval_EvalFrameEx (f=0xaa3e62c, throwflag=0) at Python/ceval.c:3659 #13 0x008d32bd in PyEval_EvalFrameEx (f=0xa93ef14, throwflag=0) at Python/ceval.c:3659 #14 0x008d32bd in PyEval_EvalFrameEx (f=0xa6422c4, throwflag=0) at Python/ceval.c:3659 #15 0x008d4922 in PyEval_EvalCodeEx (co=0x8f28e30, globals=0x8f23604, locals=0x0, args=0xa528cd8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #16 0x0087145a in function_call (func=0x8f2bf7c, arg=0xa528ccc, kw=0x0) at Objects/funcobject.c:517 #17 0x0084e917 in PyObject_Call (func=0x13e01, arg=0xa528ccc, kw=0x0) at Objects/abstract.c:1861 #18 0x008561a5 in instancemethod_call (func=0x9694284, arg=0xa528ccc, kw=0x0) at Objects/classobject.c:2519 #19 0x0084e917 in PyObject_Call (func=0x13e01, arg=0xb7ee302c, kw=0x0) at Objects/abstract.c:1861 #20 0x008cc67c in PyEval_CallObjectWithKeywords (func=0x9694284, arg=0xb7ee302c, kw=0x0) at Python/ceval.c:3442 #21 0x00903394 in t_bootstrap (boot_raw=0xaaedf98) at ./Modules/threadmodule.c:424 #22 0x00cf745b in start_thread () from /lib/libpthread.so.0 #23 0x00c2fc4e in clone () from /lib/libc.so.6 Here is the top of another backtrace that occurs when accessing a free list to allocate a Python object: #0 0x0808825b in PyObject_Malloc (nbytes=41) at Objects/obmalloc.c:747 #1 0x0808d998 in PyString_FromStringAndSize (str=0x0, size=17) at Objects/stringobject.c:75 ... ---------- components: Interpreter Core files: python_memtest.tbz messages: 78249 nosy: ajg severity: normal status: open title: Object allocation stress leads to segfault on RHEL type: crash versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file12436/python_memtest.tbz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 22:44:15 2008 From: report at bugs.python.org (Daniel Diniz) Date: Tue, 23 Dec 2008 21:44:15 +0000 Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to urllib In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za> Message-ID: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za> New submission from Daniel Diniz : This patch adds a version of urlopen that uses available encoding information to return strings instead of bytes. The main goal is to provide a shortcut for users that don't want to handle the decoding in the easy cases[1]. One added benefit it that the failures of such a function would be make it clear why 2.x style "str is either bytes or text" is flawed for network IO. Currently, charset detection simply uses addinfourl.get_charset(), but optionally checking for HTTP headers might be more robust. [1] http://groups.google.com/group/comp.lang.python/browse_thread/thread/b88239182f368505 [Executive summary] Glenn G. Chappell wrote: "2to3 doesn't catch it, and, in any case, why should read() return bytes, not string?" Carl Banks wrote: It returns bytes because it doesn't know what encoding to use. [...] HOWEVER... [...] It's reasonable that IF a url request's "Content-type" is text, and/or the "Content-encoding" is given, for urllib to have an option to automatically decode and return a string instead of bytes. Christian Heimes wrote: There is no generic and simple way to detect the encoding of a remote site. Sometimes the encoding is mentioned in the HTTP header, sometimes it's embedded in the section of the HTML document. Daniel Diniz wrote: [... A] "decode to declared HTTP header encoding" version of urlopen could be useful to give some users the output they want (text from network io) or to make it clear why bytes is the safe way. [/Executive summary] ---------- components: Library (Lib) files: urlopen_text.diff keywords: patch messages: 78250 nosy: ajaksu2 severity: normal status: open title: Add a "decode to declared encoding" version of urlopen to urllib type: feature request versions: Python 3.1 Added file: http://bugs.python.org/file12437/urlopen_text.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 23:47:30 2008 From: report at bugs.python.org (Graham Dumpleton) Date: Tue, 23 Dec 2008 22:47:30 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230072450.9.0.774308651209.issue4718@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Note that the page: http://www.wsgi.org/wsgi/Amendments_1.0 contains clarifications for WSGI PEP in respect of Python 3.0. This list was previously come up with on WEB-SIG list. As another reference implementation for Python 3.0, you might look at mod_wsgi (source code from subversion trunk), as that has been updated to support Python 3.0 in line with those list of proposed clarifications for WSGI PEP. ---------- nosy: +grahamd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 02:59:03 2008 From: report at bugs.python.org (George Yoshida) Date: Wed, 24 Dec 2008 01:59:03 +0000 Subject: [issue4734] broken link for 2.5.3 doc download In-Reply-To: <1230083943.69.0.375833328157.issue4734@psf.upfronthosting.co.za> Message-ID: <1230083943.69.0.375833328157.issue4734@psf.upfronthosting.co.za> New submission from George Yoshida : Download page for 2.5.3 documantation is not ready. --- Go to Documentation top page: http://docs.python.org/ click "Previous versions" click "Python 2.5.3" click "Download all these documents" But this URL, http://www.python.org/doc/2.5.3/download/ , gives 404 NOT FOUND ERROR. ---------- assignee: georg.brandl components: Documentation messages: 78252 nosy: georg.brandl, quiver severity: normal status: open title: broken link for 2.5.3 doc download versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:03:03 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Dec 2008 02:03:03 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1230084183.73.0.147948316166.issue1068268@psf.upfronthosting.co.za> STINNER Victor added the comment: Instead of define a method for each "syscall", you can write a generic function that retry at OSError(EINTR): def no_intr(self, func, *args, **kw): while True: try: return func(*args, **kw) except OSError, e: if e.errno == errno.EINTR: continue else: raise x=_waitpid_no_intr(pid, options) becomes x=no_intr(os.waitpid, pid, options). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:08:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Dec 2008 02:08:19 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1230084499.04.0.0924057784205.issue1068268@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, the new patch (subprocess-retry-on-EINTR-std-in-out-err.diff) has already a generic function (_no_intr) which is a little bit different than mine (looks like a decorator). Can you delete your old patch? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:25:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 24 Dec 2008 02:25:58 +0000 Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to urllib In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za> Message-ID: <1230085558.44.0.944148349434.issue4733@psf.upfronthosting.co.za> Christian Heimes added the comment: Thx, I'll review the patch after Christmas. ---------- nosy: +christian.heimes priority: -> normal stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:35:40 2008 From: report at bugs.python.org (Rodney) Date: Wed, 24 Dec 2008 02:35:40 +0000 Subject: [issue4735] An error occurred during the installation of assembly In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za> Message-ID: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za> New submission from Rodney : An error occurred during the installation of assembly 'Microsoft.VC90.CRT, version="9.0.21022.8",publicKey Token="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32". Please refer to Help and Support for more information. ---------- components: Installation messages: 78256 nosy: rwpjr66 severity: normal status: open title: An error occurred during the installation of assembly type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 09:15:35 2008 From: report at bugs.python.org (Miles) Date: Wed, 24 Dec 2008 08:15:35 +0000 Subject: [issue4736] io.BufferedRWPair.closed broken; tries to call bool writer.closed property In-Reply-To: <1230106535.65.0.877178060081.issue4736@psf.upfronthosting.co.za> Message-ID: <1230106535.65.0.877178060081.issue4736@psf.upfronthosting.co.za> New submission from Miles : The closed property of BufferedRWPair attempts to call the closed property of its writer as a method, which fails because writer.closed is a bool. The following code demonstrates the error: import socket socket.socket().makefile('rwb').closed ---------- components: Library (Lib) messages: 78257 nosy: semanticist severity: normal status: open title: io.BufferedRWPair.closed broken; tries to call bool writer.closed property type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 09:30:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 24 Dec 2008 08:30:39 +0000 Subject: [issue4734] broken link for 2.5.3 doc download In-Reply-To: <1230083943.69.0.375833328157.issue4734@psf.upfronthosting.co.za> Message-ID: <1230107439.72.0.292278476912.issue4734@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report; this is now fixed. ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 10:42:06 2008 From: report at bugs.python.org (Matteo Bertini) Date: Wed, 24 Dec 2008 09:42:06 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1230111726.85.0.0318349654273.issue1068268@psf.upfronthosting.co.za> Changes by Matteo Bertini : Removed file: http://bugs.python.org/file11818/subprocess-retry-on-EINTR-std-in-out-err.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 11:21:21 2008 From: report at bugs.python.org (Matteo Bertini) Date: Wed, 24 Dec 2008 10:21:21 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1230114081.13.0.670766170605.issue1068268@psf.upfronthosting.co.za> Changes by Matteo Bertini : Removed file: http://bugs.python.org/file11511/subprocess-eintr-safety-25maint-r65475.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 11:36:23 2008 From: report at bugs.python.org (Matteo Bertini) Date: Wed, 24 Dec 2008 10:36:23 +0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1230114983.92.0.489301868713.issue1068268@psf.upfronthosting.co.za> Matteo Bertini added the comment: no EINTR patch upgraded to 25-maint r65475 that protects: *) all direct calls *) all returned fd I hope :P Added file: http://bugs.python.org/file12438/no-EINTR-subprocess.py-25-maint-r65475.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:26:45 2008 From: report at bugs.python.org (Kandalintsev Alexandre) Date: Wed, 24 Dec 2008 14:26:45 +0000 Subject: [issue4737] documentation and noddy*.c In-Reply-To: <1230128805.53.0.886805938361.issue4737@psf.upfronthosting.co.za> Message-ID: <1230128805.53.0.886805938361.issue4737@psf.upfronthosting.co.za> New submission from Kandalintsev Alexandre : Hello! 1) In http://docs.python.org/3.0/extending/extending.html we see: ========= Note that PyMODINIT_FUNC declares the function as void return type ========= But thats not true, it's defined as PyObject*. I think this is outdated info in documentation. 2) In Doc/includes/noddy*.c assumed that PyMODINIT_FUNC returns nothing but this wrong. If you try "python3.1 -c 'import noddy'" you will see segfault. This patch will fix this problem: --- ./noddy.c 2008-12-24 17:09:36.424870738 +0300 +++ ./noddy.c 2008-12-24 17:18:01.524869143 +0300 @@ -52,4 +52,6 @@ Py_INCREF(&noddy_NoddyType); PyModule_AddObject(m, "Noddy", (PyObject *)&noddy_NoddyType); + + return m; } Other noddy*.c files are also requiring this patch. ---------- assignee: georg.brandl components: Demos and Tools, Documentation messages: 78260 nosy: exe, georg.brandl severity: normal status: open title: documentation and noddy*.c versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:27:26 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Wed, 24 Dec 2008 14:27:26 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230128846.34.0.863056976165.issue4718@psf.upfronthosting.co.za> Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12423/wsgiref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:27:29 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Wed, 24 Dec 2008 14:27:29 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230128849.92.0.880467784058.issue4718@psf.upfronthosting.co.za> Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12429/wsgiref2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:27:32 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Wed, 24 Dec 2008 14:27:32 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230128852.29.0.228408338163.issue4718@psf.upfronthosting.co.za> Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12431/wsgiref_pep333.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:36:57 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Wed, 24 Dec 2008 14:36:57 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230129417.94.0.401440410732.issue4718@psf.upfronthosting.co.za> Dmitry Vasiliev added the comment: Attached new WSGI 1.0+ version of the patch. Added file: http://bugs.python.org/file12439/wsgiref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 16:10:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 24 Dec 2008 15:10:52 +0000 Subject: [issue4736] io.BufferedRWPair.closed broken; tries to call bool writer.closed property In-Reply-To: <1230106535.65.0.877178060081.issue4736@psf.upfronthosting.co.za> Message-ID: <1230131452.46.0.820081265575.issue4736@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report. Fixed in r67923. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 17:10:23 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 24 Dec 2008 16:10:23 +0000 Subject: [issue4729] Documentation under 'pass' statement talks about exception very early. In-Reply-To: <1230011388.24.0.107578151704.issue4729@psf.upfronthosting.co.za> Message-ID: <1230135023.92.0.293364421123.issue4729@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I agree. Changed in r67924. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 17:12:27 2008 From: report at bugs.python.org (David M. Beazley) Date: Wed, 24 Dec 2008 16:12:27 +0000 Subject: [issue1194378] sendmsg() and recvmsg() for C socket module Message-ID: <1230135147.26.0.879509972695.issue1194378@psf.upfronthosting.co.za> David M. Beazley added the comment: Bump. This functionality seems to be needed if anyone is going to be messing around with advanced features of IPv6. As it stands, the socket module in Python 2.6/3.0 is incomplete without this. ---------- nosy: +beazley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 17:27:33 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 24 Dec 2008 16:27:33 +0000 Subject: [issue4737] documentation and noddy*.c In-Reply-To: <1230128805.53.0.886805938361.issue4737@psf.upfronthosting.co.za> Message-ID: <1230136053.77.0.997025350992.issue4737@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67925. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 17:29:31 2008 From: report at bugs.python.org (ebfe) Date: Wed, 24 Dec 2008 16:29:31 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> New submission from ebfe : My application needs to pack and unpack workunits all day long and does this using multiple threading.Threads. I've noticed that the zlib module seems to use only one thread at a time when using [de]compressobj(). As the comment in the sourcefile zlibmodule.c already says the module uses a global lock to protect different threads from accessing the object. While the c-functions release the GIL while waiting for the global lock, only one thread at a time can use zlib. My app ends up using only one CPU to compress/decompress it's workunits... The patch (svn diff to ) attached here fixes this problem by extending the compressobj-structure by an additional member to create object-specific locks and removes the global lock. The lock protects each compressobj individually and allows multiple python threads to use zlib in parallel, utilizing all available CPUs. ---------- components: None files: zlib_threads.diff keywords: patch messages: 78266 nosy: ebfe severity: normal status: open title: Patch to make zlib-objects better support threads type: performance versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12440/zlib_threads.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 18:37:46 2008 From: report at bugs.python.org (David Laban) Date: Wed, 24 Dec 2008 17:37:46 +0000 Subject: [issue4739] [patch] Let users do help('@') and so on for confusing syntax constructs. In-Reply-To: <1230140265.88.0.991018728121.issue4739@psf.upfronthosting.co.za> Message-ID: <1230140265.88.0.991018728121.issue4739@psf.upfronthosting.co.za> New submission from David Laban : When I first came across decorators (about a year ago?), they confused the hell out of me, and the syntax is completely google-proof, so I ended up having to ask on irc. One of the things that I tried was help('@') but that didn't work either. This patch is to make that work, and also a lot of other google-proof syntax constructs. Notes on the patch ================== I've tried to do it with as few changes/duplications as possible, but my style is quite different from the rest of the module. I hereby donate my code to whoever wants to commit it. Do what you want with it, and clean it up however you want. I'm doing it for the n00bs. The patch is against pydoc.py from python 2.5.2-0ubuntu1. If you want me to create a patch against another version of python, send me an email. Otherwise, apply it by hand: I've tried to make as few changes as possible, so it shouldn't be too tricky. Notes on other versions of Python ================================= Python 3000 (and maybe 2.6? I've not checked) has the note: # CAUTION: if you change one of these dictionaries, be sure to adapt the # list of needed labels in Doc/tools/sphinxext/pyspecific.py and # regenerate the pydoc_topics.py file by running # make pydoc-topics # in Doc/ and copying the output file into the Lib/ directory. but all I'm doing is adding aliases, so you shouldn't need to rebuild the docs just to get help() working. Note that I've not actually tested this though. To test, I did: python -c 'import pydoc ; help(":=")' | grep 'no Python documentation found for .*' which should print: no Python documentation found for ':=' and: python -c 'import pydoc ; [help(k) for k in pydoc.help.symbols]' | grep -c 'no Python documentation found for .*' which should print nothing. ---------- assignee: georg.brandl components: Documentation files: add_symbol_help.diff keywords: patch messages: 78267 nosy: alsuren, georg.brandl severity: normal status: open title: [patch] Let users do help('@') and so on for confusing syntax constructs. type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file12441/add_symbol_help.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 18:45:02 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 24 Dec 2008 17:45:02 +0000 Subject: [issue4739] [patch] Let users do help('@') and so on for confusing syntax constructs. In-Reply-To: <1230140265.88.0.991018728121.issue4739@psf.upfronthosting.co.za> Message-ID: <1230140702.91.0.558033642504.issue4739@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 18:49:10 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 24 Dec 2008 17:49:10 +0000 Subject: [issue1194378] sendmsg() and recvmsg() for C socket module Message-ID: <1230140950.86.0.581020587464.issue1194378@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 19:24:46 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 24 Dec 2008 18:24:46 +0000 Subject: [issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k) In-Reply-To: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za> Message-ID: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : This patch enables tests for pickle.HIGHEST_PROTOCOL. (3) I confirmed test passed. ---------- components: Tests files: py3k_use_HIGHEST_PROTOCOL.patch keywords: easy, patch messages: 78268 nosy: ocean-city severity: normal stage: patch review status: open title: pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k) versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12442/py3k_use_HIGHEST_PROTOCOL.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 19:43:09 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Wed, 24 Dec 2008 18:43:09 +0000 Subject: [issue4400] pypirc default is not at the right format In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za> Message-ID: <1230144189.04.0.544766400686.issue4400@psf.upfronthosting.co.za> Changes by Tarek Ziad? : ---------- assignee: -> tarek resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 21:40:28 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Wed, 24 Dec 2008 20:40:28 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230072450.9.0.774308651209.issue4718@psf.upfronthosting.c o.za> Message-ID: <20081224204024.323D23A40A7@sparrow.telecommunity.com> Phillip J. Eby added the comment: Graham: thanks for pointing that out; I completely forgot we already *had* the migration discussion on the Web-SIG! It just slipped my mind because I didn't have any 3.0 work on the horizon. Dmitry: A question about the new patch. Are bytearray and memoryview objects in 3.0 really the same as bytestrings? It seems to me that allowing mutable bytes objects is a mistake from a bug-finding standpoint, even if it could be a win from a performance standpoint. I think it might be better to be more restrictive to start out, and then let people lobby for supporting other types, rather than the other way around, where we'll never get to narrow the list. Apart from that, the patch looks pretty good. Thank you! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 21:43:18 2008 From: report at bugs.python.org (Ultrasick) Date: Wed, 24 Dec 2008 20:43:18 +0000 Subject: [issue4741] winsound.SND_PURGE has no effect In-Reply-To: <1230151398.8.0.831706381967.issue4741@psf.upfronthosting.co.za> Message-ID: <1230151398.8.0.831706381967.issue4741@psf.upfronthosting.co.za> New submission from Ultrasick : I added a .py file to demonstrate the problem. I tryed 2 ways to stop the sound from beeing played. The first way "winsound.PlaySound(path[0] + '/sound.wav', winsound.SND_PURGE)" should already stop it but instead it starts the playback again. The second has no effect on my computer. My system: Windows 2000, service pack: 4 Python 2.6.something ---------- components: Extension Modules files: test.py messages: 78270 nosy: Ultrasick severity: normal status: open title: winsound.SND_PURGE has no effect type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12443/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 21:43:51 2008 From: report at bugs.python.org (Ultrasick) Date: Wed, 24 Dec 2008 20:43:51 +0000 Subject: [issue4741] winsound.SND_PURGE has no effect In-Reply-To: <1230151398.8.0.831706381967.issue4741@psf.upfronthosting.co.za> Message-ID: <1230151431.04.0.627690094819.issue4741@psf.upfronthosting.co.za> Ultrasick added the comment: added a test sound Added file: http://bugs.python.org/file12444/sound.wav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 22:30:43 2008 From: report at bugs.python.org (Bobby Xiao) Date: Wed, 24 Dec 2008 21:30:43 +0000 Subject: [issue1519638] Unmatched Group issue - workaround Message-ID: <1230154243.36.0.868451219096.issue1519638@psf.upfronthosting.co.za> Bobby Xiao added the comment: How would I apply that workaround to my example? re.sub("foo(?:b(ar)|baz)","\\1","foobaz") _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 23:39:27 2008 From: report at bugs.python.org (John Machin) Date: Wed, 24 Dec 2008 22:39:27 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> New submission from John Machin : File foo3.py is [cut down (orig 87Kb)] output of 2to3 conversion tool and (coincidentally) is still valid 2.x syntax. There are no syntax errors reported by any of the following: \python26\python -c "import foo3" \python26\python foo3.py \python26\python setup.py install \python30\python -c "import foo3" \python30\python foo3.py However 3.0 install \python30\python setup.py install produces: """ [snip] running install_lib copying build\lib\foo3.py -> C:\python30\Lib\site-packages byte-compiling C:\python30\Lib\site-packages\foo3.py to foo3.pyc File "C:\python30\Lib\site-packages\foo3.py", line 0 ### Note also "line 0" above ### SyntaxError: unknown encoding: cp1252 """ Same happens if alternative name windows-1252 is used instead of cp1252. NOTE: file foo3.py actually does have some non-ASCII characters (\xa0, \x93, \x94), in comments. Another file (bar3.py) from the same package contains \xb7 twice, but doesn't have the unknown encoding problem. There are several other files in the same package that start with "# -*- coding: windows-1252 -*-" (or cp1252, or even cp1251(!)) but have no non-ASCII characters in them. They don't get this incorrect error message either. ---------- components: Distutils files: py3encbug.zip messages: 78273 nosy: sjmachin severity: normal status: open title: 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 versions: Python 3.0 Added file: http://bugs.python.org/file12445/py3encbug.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 00:14:44 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 24 Dec 2008 23:14:44 +0000 Subject: [issue4741] winsound.SND_PURGE has no effect In-Reply-To: <1230151398.8.0.831706381967.issue4741@psf.upfronthosting.co.za> Message-ID: <1230160484.92.0.764727177127.issue4741@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: You should specify winsound.SND_ASYNC in first PlaySound. By default, PlaySound won't return until completing to play wav file. winsound.SND_PURGE doesn't work for me. I'm also using Win2000SP4, and I found http://www.vbforums.com/archive/index.php/t-209162.html They also think SND_PURGE doesn't work on Win2000. And MSDN says SND_PURGE is not supported. (http://msdn.microsoft.com/en- us/library/ms712879.aspx) ---------- nosy: +ocean-city _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 00:28:08 2008 From: report at bugs.python.org (John Machin) Date: Wed, 24 Dec 2008 23:28:08 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230161288.62.0.8303215474.issue4742@psf.upfronthosting.co.za> John Machin added the comment: A clue: >>> print(ascii(b'\xa0\x93\x94\xb7'.decode('cp1252'))) '\xa0\u201c\u201d\xb7' Could be that it only happens where there's a cp1252 character that's not in latin1; see files x93.py and x94.py (have problem) and xa0b7.py (doesn't have problem). Added file: http://bugs.python.org/file12446/py3encbug2.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 00:28:40 2008 From: report at bugs.python.org (John Machin) Date: Wed, 24 Dec 2008 23:28:40 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230161320.92.0.408187333414.issue4742@psf.upfronthosting.co.za> Changes by John Machin : Removed file: http://bugs.python.org/file12445/py3encbug.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 01:42:06 2008 From: report at bugs.python.org (John Machin) Date: Thu, 25 Dec 2008 00:42:06 +0000 Subject: [issue4743] intra-pkg multiple import (import local1, local2) not fixed In-Reply-To: <1230165726.07.0.804126540628.issue4743@psf.upfronthosting.co.za> Message-ID: <1230165726.07.0.804126540628.issue4743@psf.upfronthosting.co.za> New submission from John Machin : In a package, "import local1, local2" is not fixed. Here's some real live 2to3 output showing the problem and the workaround: import ExcelFormulaParser, ExcelFormulaLexer -import ExcelFormulaParser -import ExcelFormulaLexer +from . import ExcelFormulaParser +from . import ExcelFormulaLexer import sys, struct -from antlr import ANTLRException +from .antlr import ANTLRException As a solution that covers cases like "import sys, local1, local2" is possibly difficult, I suggest putting out a warning that a manual fix (one import per line) may be required. I've put this kludge in my copy of fix_import.py: def probably_a_local_import(imp_name, file_path): + if "," in imp_name: + print("*** Can't handle import %r in %s" % (imp_name, file_path)) # Must be stripped because the right space is included by the parser imp_name = imp_name.split('.', 1)[0].strip() base_path = dirname(file_path) base_path = join(base_path, imp_name) [Aside: "right space"? Possibly should be "left space"] and it produces: *** Can't handle import ' ExcelFormulaParser, ExcelFormulaLexer' in \2to3\xlwt\py3\xlwt\ExcelFormula.py *** Can't handle import ' sys, struct' in \2to3\xlwt\py3\xlwt\ExcelFormula.py ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 78276 nosy: sjmachin severity: normal status: open title: intra-pkg multiple import (import local1, local2) not fixed versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 02:22:51 2008 From: report at bugs.python.org (David M. Beazley) Date: Thu, 25 Dec 2008 01:22:51 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> New submission from David M. Beazley : The documentation for asynchat needs to be more precise in its use of strings vs. bytes. Unless the undocumented use_encoding attribute is set, it seems that all data should be bytes throughout (e.g., the terminator, inputs to push methods, etc.). I have no idea if the use_encoding attribute is officially blessed or not. However, to avoid "magic behavior", I'm guessing that it would be better practice to be explicit in one's use of bytes vs. text rather than having take place in the internals of asynchat. Advice welcome. ---------- assignee: georg.brandl components: Documentation messages: 78277 nosy: beazley, georg.brandl severity: normal status: open title: asynchat documentation needs to be more precise versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 02:46:57 2008 From: report at bugs.python.org (John Robinson) Date: Thu, 25 Dec 2008 01:46:57 +0000 Subject: [issue4745] socket.send obscure error message In-Reply-To: <1230169617.77.0.0806737582918.issue4745@psf.upfronthosting.co.za> Message-ID: <1230169617.77.0.0806737582918.issue4745@psf.upfronthosting.co.za> New submission from John Robinson : When using the socket module and performing a socket.send('hello world'), the error returned is: Traceback (most recent call last): File "C:\Python30\testclient.py", line 12, in s.send('Hello world') # send the data TypeError: send() argument 1 must be string or buffer, not str TypeError should refer to byte not string. ---------- messages: 78278 nosy: Luther severity: normal status: open title: socket.send obscure error message type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 10:35:23 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Thu, 25 Dec 2008 09:35:23 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <20081224204024.323D23A40A7@sparrow.telecommunity.com> Message-ID: <495353D5.8060609@hlabs.spb.ru> Dmitry Vasiliev added the comment: Phillip J. Eby wrote: > Graham: thanks for pointing that out; I completely forgot we already > *had* the migration discussion on the Web-SIG! It just slipped my > mind because I didn't have any 3.0 work on the horizon. Good to see we came to conclusion. Actually my first patch went in the right direction. :-) > Dmitry: A question about the new patch. Are bytearray and memoryview > objects in 3.0 really the same as bytestrings? It seems to me that > allowing mutable bytes objects is a mistake from a bug-finding > standpoint, even if it could be a win from a performance > standpoint. I think it might be better to be more restrictive to > start out, and then let people lobby for supporting other types, > rather than the other way around, where we'll never get to narrow the > list. Apart from that, the patch looks pretty good. Thank you! Actually I thought about functionality, not performance but I think you're right and mutable bytes objects also can open doors for unexpected side effects. I'll update the patch today. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 11:39:47 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Thu, 25 Dec 2008 10:39:47 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230201587.67.0.345970334965.issue4718@psf.upfronthosting.co.za> Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12439/wsgiref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 11:41:23 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Thu, 25 Dec 2008 10:41:23 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230201683.79.0.682317005352.issue4718@psf.upfronthosting.co.za> Dmitry Vasiliev added the comment: Attached updated version of the patch. Added file: http://bugs.python.org/file12447/wsgiref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 12:54:18 2008 From: report at bugs.python.org (ebfe) Date: Thu, 25 Dec 2008 11:54:18 +0000 Subject: [issue4746] Misguiding wording 3.0 c-api reference In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za> Message-ID: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za> New submission from ebfe : Quote from http://docs.python.org/3.0/c-api/arg.html, regarding the "s" argument: """ s (string or Unicode object) [const char *] Convert a Python string or Unicode object to a C pointer to a character string. You must not provide storage for the string itself; a pointer to an existing string is stored into the character pointer variable whose address you pass. """ I guess the phrase "you must not provide storage" is a failed translation and not meant like that. It should say "you are not required to provide storage". It's confusing to have such strong wording without reason. ---------- assignee: georg.brandl components: Documentation messages: 78281 nosy: ebfe, georg.brandl severity: normal status: open title: Misguiding wording 3.0 c-api reference versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 17:05:02 2008 From: report at bugs.python.org (Kuba Wieczorek) Date: Thu, 25 Dec 2008 16:05:02 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1230221102.08.0.836118974288.issue4710@psf.upfronthosting.co.za> Changes by Kuba Wieczorek : Removed file: http://bugs.python.org/file12420/zipfile_extract_dirs_r2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:14:31 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Dec 2008 23:14:31 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230246871.46.0.355018848758.issue4738@psf.upfronthosting.co.za> STINNER Victor added the comment: A call to PyThread_free_lock(this->lock) in Comp_dealloc() and Decomp_dealloc(). Comp_dealloc() and Decomp_dealloc() code may also be factorized (write a common function to free unused_data, unconsumed_tail and self). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:20:11 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Dec 2008 23:20:11 +0000 Subject: [issue4629] getopt should not accept no_argument that ends with '=' In-Reply-To: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za> Message-ID: <1230247211.01.0.762490411224.issue4629@psf.upfronthosting.co.za> STINNER Victor added the comment: Can you please also write a regression test in Lib/test/test_getopt.py? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:35:57 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Dec 2008 23:35:57 +0000 Subject: [issue1797] ctypes function pointer enhancements In-Reply-To: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za> Message-ID: <1230248157.08.0.659125212847.issue1797@psf.upfronthosting.co.za> STINNER Victor added the comment: Changes applied to trunk (and py3k) so I guess that the issue can be closed. ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 01:00:01 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 00:00:01 +0000 Subject: [issue2723] Truncate __len__() at sys.maxsize In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za> Message-ID: <1230249601.14.0.575491873679.issue2723@psf.upfronthosting.co.za> STINNER Victor added the comment: Most people disagree with the original idea (len.diff: truncate the length to sys.maxsize). I don't like rbp's patch: replace verbose error message ("Python int too large to convert to C ssize_t") by a shorter message ("Length too large"). If I want to debug my program, I prefer longer error messages. The original message contains the C type: ssize_t, useful information. I dislike both patches. Can we close this issue with resolution=invalid? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 01:41:48 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Fri, 26 Dec 2008 00:41:48 +0000 Subject: [issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path In-Reply-To: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za> Message-ID: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za> New submission from Gabriel Genellina : Attempting to directly execute a script containing non-ASCII characters in its name or path raises SyntaxError. The script contents are mostly irrelevant, except it must contain an encoding declaration (with *any* encoding, real or inexistent). Running "python foo.py" works, but invoking it directly as "foo.py" raises `SyntaxError: None`, or sometimes `SyntaxError: encoding problem: with BOM` (no BOM is present in the source file, a plain ASCII text file). C:\TEMP>cd ????? C:\TEMP\?????>type test.py # -*- coding: ascii -*- C:\TEMP\?????>C:\Apps\Python30\python.exe test.py C:\TEMP\?????>test.py SyntaxError: None To avoid any doubt, the file has no strange characters: C:\TEMP\?????>python -c "print(repr(open('test.py','rb').read()))" '# -*- coding: ascii -*-\r\n' and .py files are associated with the same interpreter: C:\TEMP\?????>assoc .py .py=Python.File C:\TEMP\?????>ftype Python.File Python.File="C:\Apps\Python30\python.exe" "%1" %* The same thing happens if the file name contains any non-ASCII character (the path may be pure ASCII). ---------- components: Interpreter Core, Windows messages: 78286 nosy: gagenellina severity: normal status: open title: SyntaxError executing a script containing non-ASCII characters in its name or path type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 01:42:35 2008 From: report at bugs.python.org (ebfe) Date: Fri, 26 Dec 2008 00:42:35 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230252155.89.0.449911021619.issue4738@psf.upfronthosting.co.za> ebfe added the comment: new svn diff Added file: http://bugs.python.org/file12448/zlib_threads.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 02:25:56 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Fri, 26 Dec 2008 01:25:56 +0000 Subject: [issue4746] Misguiding wording 3.0 c-api reference In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za> Message-ID: <1230254756.22.0.786378413915.issue4746@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Also, it isn't clear that the returned string must not be modified, and that the pointer lifetime is of the original string object itself. (This applies to all string and unicode formats). ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 02:29:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 01:29:19 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230254959.22.0.946582463178.issue4738@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file12440/zlib_threads.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 02:30:24 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 01:30:24 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230255024.59.0.22155382403.issue4738@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, the patch looks fine and I like finer locks ;-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 10:36:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 26 Dec 2008 09:36:49 +0000 Subject: [issue4741] winsound.SND_PURGE has no effect In-Reply-To: <1230151398.8.0.831706381967.issue4741@psf.upfronthosting.co.za> Message-ID: <1230284209.71.0.653995887783.issue4741@psf.upfronthosting.co.za> Georg Brandl added the comment: In any case, this is not an issue in Python as PlaySound is only a thin wrapper around the OS' function. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 10:57:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 26 Dec 2008 09:57:41 +0000 Subject: [issue4748] yield expression vs lambda In-Reply-To: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za> Message-ID: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za> New submission from Georg Brandl : With lambda, the ban on "return x" in generators can be evaded: >>> x = lambda: ((yield 1), (yield 2)) >>> list(x()) [1, 2, (None, None)] >>> dis.dis(x) 1 0 LOAD_CONST 0 (1) 3 YIELD_VALUE 4 LOAD_CONST 1 (2) 7 YIELD_VALUE 8 BUILD_TUPLE 2 11 RETURN_VALUE ---------- messages: 78291 nosy: georg.brandl priority: high severity: normal status: open title: yield expression vs lambda versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 11:54:18 2008 From: report at bugs.python.org (Graham Dumpleton) Date: Fri, 26 Dec 2008 10:54:18 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230288858.15.0.312714968902.issue4718@psf.upfronthosting.co.za> Graham Dumpleton added the comment: If making changes in wsgireg.validate, may be worthwhile also fixing up one area where it isn't strictly correct according to WSGI PEP. As per discussion: http://groups.google.com/group/python-web-sig/browse_frm/thread/b14b862ec4c620c0 the check for number of arguments supplied to wsgi.input.read() is wrong as it allows for an optional argument, when argument is supposed to mandatory. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 13:46:46 2008 From: report at bugs.python.org (Mohammad Al) Date: Fri, 26 Dec 2008 12:46:46 +0000 Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za> Message-ID: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za> New submission from Mohammad Al : It seems that RotatingFileHandler is experiencing an issue when attempting to rotate log files under Windows. The following errors are received: Traceback (most recent call last): File "C:\Python25\lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python25\lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file Traceback (most recent call last): File "C:\Python25\lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): I tried the code on Python 2.5.2 and 2.5.4 under Windows XP SP 2, with the same results. To reproduce run the attached scripts few times. The first time the handlers attempt to rotate the log files the error message above is received. In addition to crashing the application, log files are getting lost as a result, which is a serious issue. I have seen few complaints about this issue, but tickets were closed without a real resolution to the issue (unless I missed something) ---------- components: Library (Lib) files: rothandlerbug.py messages: 78293 nosy: mramahi77 severity: normal status: open title: Issue with RotatingFileHandler logging handler on Windows type: crash versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file12449/rothandlerbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 13:47:07 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Fri, 26 Dec 2008 12:47:07 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230288858.15.0.312714968902.issue4718@psf.upfronthosting.co.za> Message-ID: <4954D246.8040206@hlabs.spb.ru> Dmitry Vasiliev added the comment: Graham Dumpleton wrote: > the check for number of arguments supplied to wsgi.input.read() is wrong as it allows for an optional argument, > when argument is supposed to mandatory. I think it's a good idea. I'll update the patch soon. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 14:17:06 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Fri, 26 Dec 2008 13:17:06 +0000 Subject: [issue4604] close() seems to have limited effect In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za> Message-ID: <1230297426.04.0.813802553477.issue4604@psf.upfronthosting.co.za> Dmitry Vasiliev added the comment: Attached more generic version of the patch. ---------- nosy: +hdima Added file: http://bugs.python.org/file12450/io_fixes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 14:19:59 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 26 Dec 2008 13:19:59 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> New submission from anatoly techtonik : When tarfile is directed to create tar.gz compressed archive file in a path different from current, it saves full path information in .gz header where only filename is required. This causes problems with decompression utilities, such as 7zip. The testsuite with patch are attached. {{{ tar -czf dist\create_tar.tar.gz package 7z l dist\create_tar.tar.gz > tar.out python test_create.tar.gz.py 7z l dist\create_py.tar.gz > py.out diff -pu3 tar.out py.out }}} {{{ --- tar.out Fri Dec 26 15:12:42 2008 +++ py.out Fri Dec 26 15:12:42 2008 @@ -1,10 +1,10 @@ 7-Zip 4.57 Copyright (c) 1999-2007 Igor Pavlov 2007-12-06 -Listing archive: dist\create_tar.tar.gz +Listing archive: dist\create_py.tar.gz Date Time Attr Size Compressed Name ------------------- ----- ------------ ------------ ------------------------ -2008-12-26 15:12:41 10240 170 create_tar.tar +2008-12-26 15:03:39 10240 141 dist/create_py.tar ------------------- ----- ------------ ------------ ------------------------ - 10240 170 1 files, 0 folders + 10240 141 1 files, 0 folders }}} See also issue 1886 and msg61515 in particular ---------- components: Distutils, Library (Lib) files: test_tarfile.extrapath.zip messages: 78296 nosy: techtonik severity: normal status: open title: tarfile keeps excessive dir structure in compressed files versions: Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file12451/test_tarfile.extrapath.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 14:21:17 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 26 Dec 2008 13:21:17 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230297677.51.0.0864476406318.issue4750@psf.upfronthosting.co.za> Changes by anatoly techtonik : ---------- keywords: +patch Added file: http://bugs.python.org/file12452/tarfile.directory.fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 14:39:17 2008 From: report at bugs.python.org (ebfe) Date: Fri, 26 Dec 2008 13:39:17 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> New submission from ebfe : The hashlib functions provided by _hashopenssl.c hold the GIL all the time although the underlying openssl-library is basically thread-safe. I've attached a patch (svn diff) which basically does four things: * If python is compiled with thread-support, the EVPobject is extended by an additional PyThread_type_lock which protects the objects individually. * The 'update' function releases the GIL if the to-be-hashed object is a Bytes-object and therefor provides trustworthy locking (all other types, including subclasses, are not trustworthy!). This allows multiple threads to do hashing in parallel. * The EVP_hash function removes duplicated code. * The situation regarding unicode objects is now more meaningful. Upon passing a unicode-string to the .update() function, the original hashlib throws a "TypeError: object supporting the buffer API required" which is confusing. I think it's perfectly valid not to accept unicode-strings as input and people should required to call str.encode() upon their strings before hashing, so a well-defined byte-representation of their strings get hashed. Therefor I patched the MY_GET_BUFFER_VIEW_OR_ERROUT-macro to throw "TypeError: Unicode-objects must be encoded before hashing". This also fixes issue #1118 I've tested this patch and did not run into problems. CPU occupancy relies on the buffer-size passed to .update() as releasing the GIL is basically not worth the effort for very small buffers. More testing may be needed... ---------- components: Library (Lib) files: hashopenssl_threads.diff keywords: patch messages: 78297 nosy: ebfe severity: normal status: open title: Patch for better thread support in hashlib type: performance versions: Python 3.0 Added file: http://bugs.python.org/file12453/hashopenssl_threads.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 14:42:07 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Fri, 26 Dec 2008 13:42:07 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230298927.53.0.614570530738.issue4718@psf.upfronthosting.co.za> Dmitry Vasiliev added the comment: Added check for wsgi.input.read() argument. Added file: http://bugs.python.org/file12454/wsgiref2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 15:05:51 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 26 Dec 2008 14:05:51 +0000 Subject: [issue1885] [distutils] - error when processing the "--formats=tar" option In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> Message-ID: <1230300351.5.0.945743371924.issue1885@psf.upfronthosting.co.za> anatoly techtonik added the comment: Please reopen this bug. issue#1886 is different it take a long time until it is committed. I attach patch from Giampaolo here. ---------- keywords: +patch nosy: +techtonik versions: +Python 2.5, Python 2.7 Added file: http://bugs.python.org/file12455/issue1885.tar.removed.fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 17:12:18 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 26 Dec 2008 16:12:18 +0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1230307938.01.0.145565416806.issue1886@psf.upfronthosting.co.za> anatoly techtonik added the comment: I attach an improved patch1886.use.tarfile.module.diff that fixes all bugs addressed in this issue. It also removes second call to compression program leaving that privilege to tar. > I notice that the archive generated by tarfile module looks > different. Once I open it I see the following structure: > > dist (directory) -> archive_name.tar -> archive_name (directory) > -> other subfiles This bug is illustrated and patched (not released yet as somebody needs to reopen it) in issue 1885. The extra path component is taken from the name passed to GzipFile. ---------- nosy: +techtonik versions: +Python 2.7 Added file: http://bugs.python.org/file12456/patch1886.use.tarfile.module.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 17:15:41 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 26 Dec 2008 16:15:41 +0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1230308141.19.0.00755608168022.issue1886@psf.upfronthosting.co.za> anatoly techtonik added the comment: Oh, my mistake - the bug with extra dir component in archive is in issue4750 Second shell call to compression program is removed only for the case when tarfile or any of required compression modules are not available. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 17:30:26 2008 From: report at bugs.python.org (Roumen Petrov) Date: Fri, 26 Dec 2008 16:30:26 +0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1230309026.73.0.851651440388.issue1886@psf.upfronthosting.co.za> Roumen Petrov added the comment: about patch1886.use.tarfile.module.diff - the original tar don't support -j flag. ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 17:55:28 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 26 Dec 2008 16:55:28 +0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1230310528.1.0.636750625352.issue1886@psf.upfronthosting.co.za> anatoly techtonik added the comment: What are the systems where does this original tar still exist as a default utility? If there is no tarfile module on this systems and "tar" version is so old then you need a more modern system to wrap your releases or more modern "tar". The ratio of such systems to windows systems without tar at all is less than 1%, so it doesn't worth the hassle. But the true reason why I won't revert the part where command line "tar" is used, to a double call scheme, is that when you do not pipe "tar" with compression program and use them separately with relative path - you will get the same weird header in your tar.gz That's why it is not uncommon on windows to meet tar.gz python packages with weird paths inside. Luckily, windows users are infrequently install something from sources and if they do - the .zip option is often preferred. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 18:48:00 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2008 17:48:00 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230313680.55.0.299690129674.issue4718@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi, The patch looks ok to me, although the tests against mutable byte-like types are probably useless. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 20:55:30 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Fri, 26 Dec 2008 19:55:30 +0000 Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry values In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za> Message-ID: <1230321330.82.0.0879507448261.issue4722@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 22:06:43 2008 From: report at bugs.python.org (Andrey Petrov) Date: Fri, 26 Dec 2008 21:06:43 +0000 Subject: [issue4752] Error in SocketServer UDP documentation In-Reply-To: <1230325603.01.0.864584000034.issue4752@psf.upfronthosting.co.za> Message-ID: <1230325603.01.0.864584000034.issue4752@psf.upfronthosting.co.za> New submission from Andrey Petrov : In the SocketServer.UDPServer Example, the second last line: server = SocketServer.UDPServer((HOST, PORT), BaseUDPRequestHandler) Should be: server = SocketServer.UDPServer((HOST, PORT), MyUDPHandler) ---------- assignee: georg.brandl components: Documentation messages: 78305 nosy: georg.brandl, shazow severity: normal status: open title: Error in SocketServer UDP documentation versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 22:09:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2008 21:09:39 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This patch implements what is usually called "threaded code" for the ceval loop on compilers which support it (only gcc). The idea is that there is a separate opcode dispatch epilog at the end of each opcode, which allows the CPU to make much better use of its branch prediction capabilities. The net result is a 15-20% average speedup on pybench and pystone, with higher speedups on very tight loops (see below for the full pybench result chart). The opcode jump table is generated by a separate script which is called as part of the Makefile (just as the asdl building script already is). On compilers other than gcc, performance will of course be unchanged. Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 100ms 107ms -7.1% 101ms 110ms -8.2% BuiltinMethodLookup: 76ms 106ms -28.1% 78ms 106ms -26.5% CompareFloats: 108ms 141ms -23.2% 108ms 141ms -23.2% CompareFloatsIntegers: 171ms 188ms -9.4% 173ms 204ms -15.3% CompareIntegers: 165ms 213ms -22.6% 168ms 224ms -25.1% CompareInternedStrings: 127ms 169ms -24.6% 127ms 169ms -24.8% CompareLongs: 95ms 124ms -23.1% 95ms 126ms -24.5% CompareStrings: 109ms 136ms -20.2% 111ms 139ms -19.9% ComplexPythonFunctionCalls: 131ms 150ms -12.4% 136ms 151ms -10.2% ConcatStrings: 159ms 171ms -6.9% 160ms 173ms -7.4% CreateInstances: 148ms 157ms -5.6% 150ms 158ms -4.9% CreateNewInstances: 112ms 117ms -4.3% 112ms 118ms -4.6% CreateStringsWithConcat: 144ms 198ms -27.3% 148ms 199ms -25.7% DictCreation: 90ms 104ms -13.3% 90ms 104ms -13.1% DictWithFloatKeys: 117ms 153ms -23.7% 117ms 154ms -24.0% DictWithIntegerKeys: 104ms 153ms -32.3% 104ms 154ms -32.5% DictWithStringKeys: 90ms 140ms -35.7% 90ms 141ms -36.3% ForLoops: 100ms 161ms -38.1% 100ms 161ms -38.1% IfThenElse: 123ms 170ms -28.0% 125ms 171ms -27.1% ListSlicing: 142ms 141ms +0.3% 142ms 142ms +0.2% NestedForLoops: 135ms 190ms -29.0% 135ms 190ms -29.0% NormalClassAttribute: 249ms 281ms -11.5% 249ms 281ms -11.3% NormalInstanceAttribute: 110ms 153ms -28.2% 111ms 154ms -28.1% PythonFunctionCalls: 106ms 130ms -18.7% 108ms 131ms -17.2% PythonMethodCalls: 151ms 169ms -10.1% 152ms 169ms -9.8% Recursion: 183ms 242ms -24.7% 191ms 243ms -21.4% SecondImport: 142ms 138ms +2.7% 144ms 139ms +3.4% SecondPackageImport: 146ms 149ms -2.3% 148ms 150ms -1.5% SecondSubmoduleImport: 201ms 193ms +3.9% 201ms 195ms +3.4% SimpleComplexArithmetic: 90ms 112ms -19.6% 90ms 112ms -19.8% SimpleDictManipulation: 172ms 230ms -25.2% 173ms 231ms -25.0% SimpleFloatArithmetic: 98ms 133ms -26.3% 99ms 137ms -27.9% SimpleIntFloatArithmetic: 134ms 175ms -23.6% 138ms 176ms -21.6% SimpleIntegerArithmetic: 134ms 183ms -26.8% 141ms 183ms -23.1% SimpleListManipulation: 91ms 143ms -36.3% 93ms 143ms -35.1% SimpleLongArithmetic: 88ms 108ms -17.9% 91ms 109ms -16.2% SmallLists: 127ms 162ms -21.6% 129ms 164ms -21.2% SmallTuples: 149ms 177ms -15.6% 151ms 178ms -15.1% SpecialClassAttribute: 423ms 426ms -0.7% 426ms 430ms -0.9% SpecialInstanceAttribute: 110ms 154ms -28.2% 111ms 154ms -28.3% StringMappings: 428ms 443ms -3.4% 432ms 449ms -3.7% StringPredicates: 124ms 161ms -23.1% 125ms 162ms -22.7% StringSlicing: 207ms 223ms -7.1% 208ms 228ms -8.7% TryExcept: 72ms 166ms -56.3% 73ms 166ms -56.2% TryFinally: 93ms 120ms -22.9% 93ms 124ms -25.2% TryRaiseExcept: 52ms 64ms -19.2% 52ms 65ms -19.2% TupleSlicing: 177ms 195ms -9.1% 178ms 198ms -10.2% WithFinally: 147ms 163ms -10.2% 147ms 164ms -10.1% WithRaiseExcept: 156ms 173ms -10.1% 157ms 174ms -9.7% ------------------------------------------------------------------------------- Totals: 6903ms 8356ms -17.4% 6982ms 8443ms -17.3% ---------- components: Interpreter Core files: threadedceval1.patch keywords: patch messages: 78306 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: Faster opcode dispatch on gcc type: performance versions: Python 3.1 Added file: http://bugs.python.org/file12457/threadedceval1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 22:22:48 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2008 21:22:48 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230326568.46.0.825616195644.issue4753@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Armin, by reading the pypy-dev mailing-list it looks like you were interested in this. ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 22:42:10 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 21:42:10 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230327730.92.0.273208459906.issue4751@psf.upfronthosting.co.za> STINNER Victor added the comment: I think that you don't use Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS correctly: the GIL can be released when the hashlib lock is acquired (to run hash functions in parallel threads). So the macros should be: #define ENTER_HASHLIB \ PyThread_acquire_lock(self->lock, 1); \ Py_BEGIN_ALLOW_THREADS #define LEAVE_HASHLIB \ Py_END_ALLOW_THREADS \ PyThread_release_lock(self->lock); If I'm right, issue #4738 (zlib) is also affected. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 22:57:17 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2008 21:57:17 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230328637.71.0.051297878638.issue4751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi, Very good idea. However, you don't need to discriminate for the bytes type specifically. When a buffer is taken on the object (with PyObject_GetBuffer()), the object is internally "locked" until the buffer is release with PyBuffer_Release(). Try with a bytearray and you'll see: if you resize the bytearray while hashing it in another thread, you'll get a BufferError exception. All in all, it should make your code and macros much simpler. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 23:00:08 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Fri, 26 Dec 2008 22:00:08 +0000 Subject: [issue4726] doctest gets line numbers wrong due to quotes in comments In-Reply-To: <1229970384.34.0.779810047928.issue4726@psf.upfronthosting.co.za> Message-ID: <1230328808.55.0.899344937173.issue4726@psf.upfronthosting.co.za> Gabriel Genellina added the comment: I could not reproduce the behaviour you describe. Could you provide a test case? That fails with the current code and is fixed after applying your patch. (BTW, the r.e. should be a raw string literal, even the original one) ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 23:01:23 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 22:01:23 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230328883.38.0.604688552664.issue4751@psf.upfronthosting.co.za> STINNER Victor added the comment: EVP_copy() and EVP_get_digest_size() should call ENTER_HASHLIB/LEAVE_HASHLIB to protect self->ctx. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 23:28:57 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2008 22:28:57 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230330537.04.0.931118167917.issue4738@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou priority: -> normal stage: -> patch review versions: -Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 23:32:37 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 22:32:37 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230330757.97.0.710407230501.issue4751@psf.upfronthosting.co.za> STINNER Victor added the comment: If view.len is negative, EVP_hash() may read invalid memory :-/ Be careful of integer overflow in this block: Py_ssize_t offset = 0, sublen = len; while (sublen) { unsigned int process = sublen > MUNCH_SIZE ? MUNCH_SIZE : sublen; ... } You removed Py_SAFE_DOWNCAST(len, Py_ssize_t, unsigned int) which should be used (eg. on process?). Note: you might modify len directly instead of using a second variable (sublen), and cp instead of using an offset. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 23:49:06 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 26 Dec 2008 22:49:06 +0000 Subject: [issue4754] winsound documentation (about stoping sounds) In-Reply-To: <1230331746.17.0.591336113969.issue4754@psf.upfronthosting.co.za> Message-ID: <1230331746.17.0.591336113969.issue4754@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : This comes from Issue4741. The patch - clarify meaning of None as the parameter of *sound* to PlaySound - notify SND_PURGE is not supported by MS now ---------- assignee: georg.brandl components: Documentation files: winsound_doc.patch keywords: patch messages: 78313 nosy: georg.brandl, ocean-city severity: normal status: open title: winsound documentation (about stoping sounds) versions: Python 2.6 Added file: http://bugs.python.org/file12458/winsound_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 23:50:23 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 26 Dec 2008 22:50:23 +0000 Subject: [issue4754] winsound documentation (about stoping sounds) In-Reply-To: <1230331746.17.0.591336113969.issue4754@psf.upfronthosting.co.za> Message-ID: <1230331823.56.0.19221198012.issue4754@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: The patch is for release26-maint. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:03:23 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Fri, 26 Dec 2008 23:03:23 +0000 Subject: [issue4716] Python 3.0 halts on shutdown when settrace is set In-Reply-To: <1229944146.69.0.613877137046.issue4716@psf.upfronthosting.co.za> Message-ID: <1230332603.03.0.910900048123.issue4716@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Yes, this is exactly the problem. The execution never goes beyond print ('here'); if you print frame.f_lineno you'll see it blocks at io.py line 1036, waiting for a Lock for the second time. So the trace function cannot use print, not write to regular files (because io.py is written in Python). This is a severe limitation. As a workaround, you can use the _fileio module (written in C): import _fileio f = _fileio._FileIO("output.txt", "w", True) def tracing_func(frame, event, arg): f.write('%s %s %d\n' % (frame.f_code.co_filename, frame.f_code.co_ name, frame.f_lineno)) return tracing_func A possible fix would be to use an RLock instead of a Lock object, but I haven't investigated it. ---------- components: +Library (Lib) nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:17:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2008 23:17:35 +0000 Subject: [issue4716] Python 3.0 halts on shutdown when settrace is set In-Reply-To: <1229944146.69.0.613877137046.issue4716@psf.upfronthosting.co.za> Message-ID: <1230333455.22.0.472237678493.issue4716@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the investigation! The problem has already been reported in #3618. Closing this one. ---------- resolution: -> duplicate status: open -> closed superseder: -> possible deadlock in IO library (Lib/io.py) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:18:30 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 23:18:30 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230333510.54.0.191043591997.issue4751@psf.upfronthosting.co.za> STINNER Victor added the comment: New version of ebfe's patch: - ENTER/LEAVE_HASHLIB: * don't touch GIL in ENTER_HASHLIB (it's useless) * add mandatory argument (explicit use of "self") - EVP_hash(): * restore Py_SAFE_DOWNCAST * simplify the code: always use the while() instead of if+while * use "while (0 < len)" to skip zero or negative value (even if pitrou told me that len should not be negative) - EVP_dealloc(): free the lock before the context - release the GIL for all calls to EVP_hash() - use the context lock in EVP_copy() and EVP_get_digest_size() to protect self - don't use the context lock in EVP_repr() (useless because we don't read OpenSSL context) - fix the indentation of the code (replace tab by spaces) Some rules for ENTER/LEAVE_HASHLIB: * it is only needed to protect the context attribute (eg. name doesn't need to be protected by the lock) * it doesn't touch the GIL: use an explicit call to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS About the GIL: * EVP_DigestInit() and EVP_MD_CTX_copy() are consired fast enough to no release the GIL * The GIL is released for the slowest function: EVP_DigestUpdate() (called in our EVP_hash() function) Added file: http://bugs.python.org/file12459/hashopenssl_threads-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:34:43 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 23:34:43 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230334483.87.0.968265075301.issue4738@psf.upfronthosting.co.za> STINNER Victor added the comment: New comments about the last patch: - GIL is not released for adler() or crc32() whereas these functions may be slow for long strings: just add Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS before / after adler(...) and crc32(...) - (As ENTER_HASHLIB, issue #4751) I think that Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS are useless in ENTER_ZLIB - You might add explicit self to ENTER/LEAVE_ZLIB because the macros are now dependent of self (and not the whole module) => ENTER_ZLIB(self) and LEAVE_ZLIB(self) Are deflateCopy() and inflateCopy() slow enough to release the GIL? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:45:14 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 23:45:14 +0000 Subject: [issue3860] GzipFile and BZ2File should support context manager protocol In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za> Message-ID: <1230335114.05.0.823259373091.issue3860@psf.upfronthosting.co.za> STINNER Victor added the comment: I love "with ... as f:" and I want it for gzip/bz2 files! Comment about the patch: (1) the IOError message is different for the two modules: "I/O operation on closed GzipFile object" vs "I/O operation on closed file" Specify the object name in both messages or remove it from both messages. I prefer verbose error message ("I/O operation on closed BZ2File object"). (2) For bz2module, Why don't you call BZ2File_close() directly instead of the generic version PyObject_CallMethod(... "close" ...)? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:53:52 2008 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2008 23:53:52 +0000 Subject: [issue4640] optparse - dosn't distinguish between '--option' and '-option' In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za> Message-ID: <1230335632.39.0.477640572661.issue4640@psf.upfronthosting.co.za> STINNER Victor added the comment: -debug may be equivalent to -d -e -b -u -g (if none of these options have an argument), but no to --debug. If you like to use -d as an alias to --debug, just use: add_option("-d", "--debug", ...). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:57:33 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Fri, 26 Dec 2008 23:57:33 +0000 Subject: [issue4708] os.pipe should return inheritable descriptors (Windows) In-Reply-To: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za> Message-ID: <1230335853.96.0.460773711316.issue4708@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Patch to posixmodule.c including test case and documentation updates. Note: I've only run the tests on Windows. ---------- keywords: +patch Added file: http://bugs.python.org/file12460/inheritable_pipes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 01:11:05 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 00:11:05 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230336665.08.0.146570457467.issue4751@psf.upfronthosting.co.za> Changes by ebfe : Removed file: http://bugs.python.org/file12453/hashopenssl_threads.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 01:20:47 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 00:20:47 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230337247.88.0.869574524229.issue4751@psf.upfronthosting.co.za> ebfe added the comment: Thanks for the advices. Antoine, maybe you could clarify the situation regarding buffer-locks for me. In older versions of PEP 3118 the PyBUF_LOCK flag was still present but it doesn't seem to have made it's way into the final draft. Is it save to assume that a buffer-view will not change until release() is called - for all types supporting the buffer protocol in py3k ?? I've done some testing and the overhead of releasing and re-locking the GIL is definitely a performance problem when trying to hash many small strings (doubled runtime for 100.000 times b'abc'). I've taken on haypo's patch to release the GIL only when the buffer is larger than 10kb. Added file: http://bugs.python.org/file12461/hashopenssl_threads-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 01:44:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 00:44:15 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230337247.88.0.869574524229.issue4751@psf.upfronthosting.co.za> Message-ID: <1230338655.31901.13.camel@localhost> Antoine Pitrou added the comment: > Is it save to assume that a buffer-view will not change until release() > is called - for all types supporting the buffer protocol in py3k ?? Yes, it is! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 01:46:10 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 00:46:10 +0000 Subject: [issue3860] GzipFile and BZ2File should support context manager protocol In-Reply-To: <1230335114.05.0.823259373091.issue3860@psf.upfronthosting.co.za> Message-ID: <1230338767.31901.15.camel@localhost> Antoine Pitrou added the comment: > (1) the IOError message is different for the two modules: > "I/O operation on closed GzipFile object" > vs > "I/O operation on closed file" I've reused the same error message as used in other parts of each module. > (2) For bz2module, Why don't you call BZ2File_close() directly instead > of the generic version PyObject_CallMethod(... "close" ...)? Because someone may subclass BZ2File and override the close() method. I don't know if it's likely to happen, though. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:04:05 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 01:04:05 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230339845.8.0.60880428439.issue4751@psf.upfronthosting.co.za> STINNER Victor added the comment: > I've taken on haypo's patch to release the GIL only > when the buffer is larger than 10kb You can factorize the code by moving Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS *into* EVP_hash ;-) 10 KB is a random value or the fast value for your computer? I wrote a small benchmark: md5sum.py, my Python multithreaded version of md5sum. Results on 129 files (between 7 and 10 MB) on an Intel Quad Core @ 2.5 GHz: - without the patch: best=10.6 sec / average ~= 11.5 sec - with the patch (version 3): best=7.7 sec / average ~= 8.5 sec My program creates N threads for N files, which is maybe stupid (eg. limit to C+1 thread for C cores). Added file: http://bugs.python.org/file12462/md5sum.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:15:23 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 01:15:23 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230340523.67.0.773830089256.issue4738@psf.upfronthosting.co.za> ebfe added the comment: new svn diff attached - GIL is now released for adler32 and crc32 if the buffer is larger than 5kb (we don't want to risk burning cpu cycles by GIL-stuff) - adler32 got it's param by s# but now does s* - why s# anyway? - ENTER_ZLIB no longer gives away the GIL. It's dangerous and useless as there is no pressure on the object's lock. - deflateCopy() and inflateCopy() are not worth the trouble.u Added file: http://bugs.python.org/file12463/zlib_threads-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:15:30 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 01:15:30 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230340530.38.0.353472607792.issue4738@psf.upfronthosting.co.za> Changes by ebfe : Removed file: http://bugs.python.org/file12448/zlib_threads.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:27:15 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 01:27:15 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230341235.17.0.460055069816.issue4751@psf.upfronthosting.co.za> STINNER Victor added the comment: New version of my md5sum.py program limited to 10 threads. New benchmark with 160 files (size in 7..10 MB): - Python unpatched: best=4.8 sec - C version (/usr/bin/md5sum): best=3.6 sec - Python patched: best=2.1 sec As everybody knows, Python is faster than the C language ;-) And the patch is really useful (the program is more than twice faster with 4 cores). Added file: http://bugs.python.org/file12464/md5sum.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:27:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 01:27:19 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230341239.69.0.648125013552.issue4751@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file12462/md5sum.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:36:46 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 01:36:46 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230341806.45.0.208344921281.issue4751@psf.upfronthosting.co.za> ebfe added the comment: Here is another simple benchmarker. For me it shows almost perfect scaling (2 cores = 196% performance) if the buffer put into .update() is large enough. I deliberately did not move Py_BEGIN_ALLOW_THREADS into EVP_hash as we might call this function without having some lock on the input buffer. The 10kb limit was based on my own computer (MacBook Pro 2x2.5GHz) and is somewhat more-safe-than-sorry. Hashing is *very* fast on modern CPUs and working on many small strings becomes very inefficient when releasing the GIL all the time. Just try to hash 10240 bytes vs. 10241 bytes. Added file: http://bugs.python.org/file12465/hashlibtest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:38:07 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 01:38:07 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230341887.32.0.0265447410962.issue4738@psf.upfronthosting.co.za> STINNER Victor added the comment: Comments on zlib_threads-2.diff: - the indentation is strange: don't mix spaces and tabs! - I prefer ";" after a call to a macro: "ENTER_ZLIB(self);" instead of "ENTER_ZLIB(self)". It makes vim happy (auto indent code correctly) and it works for ENTER_ZLIB and LEAVER_ZLIB. - ENTER_ZLIB and LEAVER_ZLIB prototype is wrong if WITH_THREAD is not defined - oh yeah, s* is needed to protect the buffer with a lock - why 5kb? is it a random value? I prefer power of two, like 4096 bytes :-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 02:45:13 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 01:45:13 +0000 Subject: [issue4751] Patch for better thread support in hashlib In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za> Message-ID: <1230342313.91.0.519712466038.issue4751@psf.upfronthosting.co.za> STINNER Victor added the comment: hashlibtest.py results on my Quad Core with 4 threads: - unpatched: best=13.0 sec - patched: best=3.25 sec Some maths: 13.0 / 4 = 3.25 \o/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 03:02:45 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 02:02:45 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230343365.93.0.619533861968.issue4738@psf.upfronthosting.co.za> ebfe added the comment: new svn diff attached the indentation in this file is not my fault, it has tabs all over it... The 5kb limits protects from the overhead of releasing the GIL. With very small buffers the overall runtime in my benchmark tends to double. I set it based on my testing and it remains being arbitrary to a certain degree. Set the limit to 1 and try 1.000.000 times b'abc'... May I also suggest to change the zlib module not to accept s* but y*: - Internally zlib operates on bytes, characters don't mean a thing in zlib-land. - We rely on s* performing the encoding into default for us. This behaviour is hidden from the programmer and somewhat violates the rule of least surprise. - type(zlib.decompress(zlib.compress('abc'))) == bytes - Changing from s* to y* forces the programmer to use .encode() on his strings (e.g. zlib.compress('abc'.encode()) which very clearly shows what's happening. Added file: http://bugs.python.org/file12466/zlib_threads-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 03:02:58 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Dec 2008 02:02:58 +0000 Subject: [issue4748] yield expression vs lambda In-Reply-To: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za> Message-ID: <1230343378.03.0.525342736712.issue4748@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Attaching patch? BTW, how did you find this bug? :) ---------- keywords: +needs review, patch nosy: +benjamin.peterson stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file12467/nasty_lambda_generators.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 03:03:02 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 02:03:02 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230343382.25.0.441839278531.issue4738@psf.upfronthosting.co.za> Changes by ebfe : Removed file: http://bugs.python.org/file12463/zlib_threads-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 03:41:46 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 27 Dec 2008 02:41:46 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1230345706.05.0.0916726721837.issue4744@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola, josiah.carlson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 03:50:14 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Dec 2008 02:50:14 +0000 Subject: [issue4743] intra-pkg multiple import (import local1, local2) not fixed In-Reply-To: <1230165726.07.0.804126540628.issue4743@psf.upfronthosting.co.za> Message-ID: <1230346214.96.0.944000689236.issue4743@psf.upfronthosting.co.za> Benjamin Peterson added the comment: r67928 makes 2to3 more tolerant about multiple imports on a line. It also warns when there is an absolute import and relative import on the same line. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 03:58:44 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Dec 2008 02:58:44 +0000 Subject: [issue4745] socket.send obscure error message In-Reply-To: <1230169617.77.0.0806737582918.issue4745@psf.upfronthosting.co.za> Message-ID: <1230346724.3.0.720074682093.issue4745@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r67929. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 04:19:38 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Dec 2008 03:19:38 +0000 Subject: [issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k) In-Reply-To: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za> Message-ID: <1230347978.13.0.344744831345.issue4740@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Looks fine to me. This happens in the trunk already, right? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 04:31:21 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 27 Dec 2008 03:31:21 +0000 Subject: [issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k) In-Reply-To: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za> Message-ID: <1230348681.46.0.404636584557.issue4740@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Not yet. This patch is for trunk. But HIGHEST_PROTOCOL is 2 in trunk, so no difference in behavior. (Just useful for consistency) Added file: http://bugs.python.org/file12468/trunk_use_HIGHEST_PROTOCOL.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 04:47:07 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Dec 2008 03:47:07 +0000 Subject: [issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k) In-Reply-To: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za> Message-ID: <1230349627.99.0.631679224773.issue4740@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Go ahead. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 05:00:35 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 27 Dec 2008 04:00:35 +0000 Subject: [issue4755] Common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> New submission from Skip Montanaro : os.path.commonprefix returns the common prefix of a list of paths taken character-by-character. This can return invalid paths. For example, os.path.commonprefix(["/export/home/dave", "/etc/passwd"]) will return "/e", which likely has no meaning as a path, at least in the context of the input list. Ideally, os.path.commonprefix would operate component-by-component, but people rely on the existing character-by-character operation, so it has been so far impossible to change semantics. There are several possible ways to solve this problem. One, change how commonprefix behaves. Two, add a flag to commonprefix to allow it to operate component-by-component if desired. Three, add a new function to os.path. I personally prefer the first option. Aside from the semantic change though, it presents the problem of where to put the old definition of commonprefix. It's clearly of some use or people wouldn't have co- opted it for non-filesystem use. It could go in the string module, but that's been living a life in limbo since the creation of string methods. People have been loathe to add new functionality there. The second option seems to me like would just be a hack on top of already broken behavior and probably require the currently slightly broken behavior as the default to boot, so I won't go there. Since option one is perhaps not going to be available to me, I've implemented the third option as a new function, commonpathprefix. See the attached patch. It includes test cases and documentation changes. ---------- components: Library (Lib) files: cpp.diff keywords: needs review, patch, patch messages: 78338 nosy: skip.montanaro severity: normal stage: patch review status: open title: Common path prefix type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file12469/cpp.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 05:24:12 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 27 Dec 2008 04:24:12 +0000 Subject: [issue4755] Common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1230351852.39.0.694414055794.issue4755@psf.upfronthosting.co.za> Nick Coghlan added the comment: A new function sounds like a good solution to me. How about just calling it "os.path.commonpath" though? I agree having a path component based prefix function in os.path is highly desirable, particularly since the addition of relpath in 2.6: base_dir = os.path.commonpath(paths) rel_paths = [os.path.relpath(p, base_dir) for p in paths] ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 05:44:01 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 27 Dec 2008 04:44:01 +0000 Subject: [issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k) In-Reply-To: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za> Message-ID: <1230353041.47.0.684797115157.issue4740@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Done. Fixed in r67930(trunk), r67931(py3k) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 05:44:14 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 27 Dec 2008 04:44:14 +0000 Subject: [issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k) In-Reply-To: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za> Message-ID: <1230353054.73.0.567569858622.issue4740@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 06:33:20 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 27 Dec 2008 05:33:20 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1230356000.33.0.540504907798.issue4710@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Your usage of os.sep is incorrect, both when reading and writing directories. Zip files are (more-or-less) platform independent. The specification *requires* forward slashes in paths [1], and the zipfile module already writes them that way. Checking for os.sep is wrong - at least on Windows. I've never encountered malformed entries of that kind (like "directory \" instead of "directory/") but if you want to suport such beasts, check for "/" *and* os.sep explicitely. [1] See APPNOTE.TXT (there is a link near the top of zipfile.py) ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 06:44:09 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 27 Dec 2008 05:44:09 +0000 Subject: [issue4756] zipfile.is_zipfile: added support for file-like objects In-Reply-To: <1230356647.32.0.19774175032.issue4756@psf.upfronthosting.co.za> Message-ID: <1230356647.32.0.19774175032.issue4756@psf.upfronthosting.co.za> New submission from Gabriel Genellina : Patch to zipfile.is_zipfile, adding support for file and file-like objects. Includes test cases and documentation updates. This fixes issue4241 too. ---------- components: Library (Lib) files: is_zipfile_filelike.diff keywords: patch messages: 78342 nosy: gagenellina severity: normal status: open title: zipfile.is_zipfile: added support for file-like objects type: behavior versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file12470/is_zipfile_filelike.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 06:45:57 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 27 Dec 2008 05:45:57 +0000 Subject: [issue4241] zipfile.py -> is_zipfile leaves file open when error In-Reply-To: <1225367525.69.0.93727529387.issue4241@psf.upfronthosting.co.za> Message-ID: <1230356757.22.0.607190029878.issue4241@psf.upfronthosting.co.za> Gabriel Genellina added the comment: The patch for issue4756 fixes this too. ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 07:02:06 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 27 Dec 2008 06:02:06 +0000 Subject: [issue3618] possible deadlock in IO library (Lib/io.py) In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za> Message-ID: <1230357726.49.0.0528616037816.issue3618@psf.upfronthosting.co.za> Changes by Gabriel Genellina : ---------- nosy: +gagenellina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 09:44:54 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 27 Dec 2008 08:44:54 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230367494.03.0.209411930928.issue4750@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Lars, what do you think? ---------- assignee: -> lars.gustaebel nosy: +lars.gustaebel, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 09:51:53 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 27 Dec 2008 08:51:53 +0000 Subject: [issue4746] Misguiding wording 3.0 c-api reference In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za> Message-ID: <4955ECA5.7060501@v.loewis.de> Martin v. L?wis added the comment: > I guess the phrase "you must not provide storage" is a failed > translation and not meant like that. It should say "you are not required > to provide storage". It's confusing to have such strong wording without > reason. It's stronger than "you are not required to": if you do provide storage (by allocating memory), then this memory most likely will be garbage, and you must not attempt to free it afterwards (as doing so would cause a crash). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 10:21:40 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 27 Dec 2008 09:21:40 +0000 Subject: [issue4730] cPickle corrupts high-unicode strings In-Reply-To: <1230035446.04.0.56766649246.issue4730@psf.upfronthosting.co.za> Message-ID: <1230369700.37.0.771424121537.issue4730@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Fixed in r67934. Backported to 2.6 in r67936. Thanks! ---------- nosy: +alexandre.vassalotti resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 10:31:01 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 27 Dec 2008 09:31:01 +0000 Subject: [issue4374] Pickle tests fail w/o _pickle extension In-Reply-To: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za> Message-ID: <1230370261.0.0.827011361322.issue4374@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Committed in r67940. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 10:32:12 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 27 Dec 2008 09:32:12 +0000 Subject: [issue4374] Pickle tests fail w/o _pickle extension In-Reply-To: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za> Message-ID: <1230370332.0.0.351684558874.issue4374@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 11:30:59 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Sat, 27 Dec 2008 10:30:59 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230313680.55.0.299690129674.issue4718@psf.upfronthosting.co.za> Message-ID: <495603E0.9070001@hlabs.spb.ru> Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > The patch looks ok to me, although the tests against mutable byte-like > types are probably useless. Hmm, it's strange because such tests was removed two versions ago (per discussion with Phillip). But at the time they really was needed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 11:33:10 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 10:33:10 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <495603E0.9070001@hlabs.spb.ru> Message-ID: <1230373989.10427.3.camel@localhost> Antoine Pitrou added the comment: > Hmm, it's strange because such tests was removed two versions ago (per > discussion with Phillip). But at the time they really was needed. Not a big deal anyway, let's keep them and we'll see. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 11:38:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 10:38:42 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230374322.94.0.104295692762.issue4738@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > May I also suggest to change the zlib module not to accept s* but y* You are probably right, but this would also break the API and can't be done lightheartedly. You can open a new bug entry about this though. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 12:12:19 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Sat, 27 Dec 2008 11:12:19 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230373989.10427.3.camel@localhost> Message-ID: <49560D90.4080805@hlabs.spb.ru> Dmitry Vasiliev added the comment: Antoine Pitrou wrote: >> Hmm, it's strange because such tests was removed two versions ago (per >> discussion with Phillip). But at the time they really was needed. > > Not a big deal anyway, let's keep them and we'll see. I'm afraid I've lost your point here. Are you proposing to add back tests for mutable bytes-like objects? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 12:14:46 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 11:14:46 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230376486.4.0.293377593204.issue4718@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why do you say they were removed? I see code like "assert isinstance(value, bytes)". _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 12:34:05 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Sat, 27 Dec 2008 11:34:05 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1230376486.4.0.293377593204.issue4718@psf.upfronthosting.co.za> Message-ID: <495612AB.5090907@hlabs.spb.ru> Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > Why do you say they were removed? I see code like "assert > isinstance(value, bytes)". Support and tests for mutable "bytearray" and "memoryview" was removed. All subclasses of "bytes" must be immutable so isinstance() should be OK here. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 12:42:55 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 11:42:55 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <495612AB.5090907@hlabs.spb.ru> Message-ID: <1230378172.10427.4.camel@localhost> Antoine Pitrou added the comment: Ok, sorry for the misunderstanding. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 12:49:59 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 27 Dec 2008 11:49:59 +0000 Subject: [issue1885] [distutils] - error when processing the "--formats=tar" option In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> Message-ID: <1230378599.24.0.504110911471.issue1885@psf.upfronthosting.co.za> Changes by Tarek Ziad? : ---------- assignee: -> tarek nosy: +tarek status: closed -> open Added file: http://bugs.python.org/file12471/1885.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 13:45:41 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 27 Dec 2008 12:45:41 +0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1230381941.7.0.326611096859.issue1886@psf.upfronthosting.co.za> Roumen Petrov added the comment: Did I misunderstood something about -j -z -Z flags ? http://src.opensolaris.org /source/xref/onnv/onnv-gate/usr/src/cmd/tar/tar.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 13:58:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 12:58:19 +0000 Subject: [issue4757] reject unicode in zlib In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za> Message-ID: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za> New submission from STINNER Victor : Python 2.x allows to encode any byte string (str) and ASCII unicode string (unicode): $ python Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>> import zlib >>> zlib.compress('abc') "x\x9cKLJ\x06\x00\x02M\x01'" >>> zlib.compress(u'abc') "x\x9cKLJ\x06\x00\x02M\x01'" >>> zlib.compress(u'abc\xe9') ... UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' ... I'm not sure that this behaviour was really wanted become the decompress operation is not symetric (the result type is always byte string): $ python Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>> import zlib >>> zlib.decompress("x\x9cKLJ\x06\x00\x02M\x01'") 'abc' --- Python 3.0 accepts any string: bytes or characters. But decompress always produce bytes string: $ ./python Python 3.1a0 (py3k:67926M, Dec 26 2008, 23:59:07) >>> import zlib >>> zlib.compress(b'abc') b"x\x9cKLJ\x06\x00\x02M\x01'" >>> zlib.compress('abc') b"x\x9cKLJ\x06\x00\x02M\x01'" >>> zlib.compress('abc\xe9') b'x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93' >>> zlib.compress('abc\xe9'.encode('utf-8')) b'x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93' >>> zlib.decompress(b'x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93') b'abc\xc3\xa9' The most strange operation is the decompression of an unicode string: $ ./python >>> zlib.decompress('x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93') ... zlib.error: Error -3 while decompressing data: incorrect header check --- I propose to change zlib API to reject unicode string and use explicit conversion to/from bytes. Functions/methods: - compress(bytes, ...) - decompress(bytes, ...) - .compress(bytes, ...) - .decompress(bytes, ...) - crc32(bytes, value=0) - adler(bytes, value=1) Note: binascii.crc32() already rejects unicode string. The behaviour may kept in Python 3.0.x and only changed in Python 3.1. ---------- components: Extension Modules files: zlib_bytes.patch keywords: patch messages: 78356 nosy: haypo severity: normal status: open title: reject unicode in zlib type: behavior versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12472/zlib_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:00:01 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 13:00:01 +0000 Subject: [issue4757] reject unicode in zlib In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za> Message-ID: <1230382801.92.0.353595826408.issue4757@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #4738 (better threads support in zlib). ---------- nosy: +ebfe, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:00:43 2008 From: report at bugs.python.org (David M. Beazley) Date: Sat, 27 Dec 2008 13:00:43 +0000 Subject: [issue1194378] sendmsg() and recvmsg() for C socket module Message-ID: <1230382843.91.0.519709840933.issue1194378@psf.upfronthosting.co.za> David M. Beazley added the comment: Just a followup comment to note that adding support for sendmsg()/recvmsg() is what you need to do "file descriptor passing" between processes on Unix---another technique for writing network servers. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:01:01 2008 From: report at bugs.python.org (STINNER Victor) Date: Sat, 27 Dec 2008 13:01:01 +0000 Subject: [issue4738] Patch to make zlib-objects better support threads In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za> Message-ID: <1230382861.99.0.0602811400699.issue4738@psf.upfronthosting.co.za> STINNER Victor added the comment: I opened a separate issue for the unicode problem: #4757. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:04:35 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 27 Dec 2008 13:04:35 +0000 Subject: [issue1885] [distutils] - error when processing the "--formats=tar" option In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> Message-ID: <1230383075.32.0.786733707613.issue1885@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file12471/1885.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:04:45 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 27 Dec 2008 13:04:45 +0000 Subject: [issue1885] [distutils] - error when processing the "--formats=tar" option In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> Message-ID: <1230383085.99.0.646025934489.issue1885@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Added file: http://bugs.python.org/file12473/1885.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:13:14 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 27 Dec 2008 13:13:14 +0000 Subject: [issue4757] reject unicode in zlib In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za> Message-ID: <495629E8.1080408@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-27 13:58, STINNER Victor wrote: > Python 2.x allows to encode any byte string (str) and ASCII unicode > string (unicode): > > $ python > Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>>> import zlib >>>> zlib.compress('abc') > "x\x9cKLJ\x06\x00\x02M\x01'" >>>> zlib.compress(u'abc') > "x\x9cKLJ\x06\x00\x02M\x01'" >>>> zlib.compress(u'abc\xe9') > ... > UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' ... > > I'm not sure that this behaviour was really wanted become the > decompress operation is not symetric (the result type is always byte > string): > > $ python > Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>>> import zlib >>>> zlib.decompress("x\x9cKLJ\x06\x00\x02M\x01'") > 'abc' > I don't see a problem with this. The fact that Python 2.x also accepts Unicode ASCII strings where strings are normally expected is intended to help with the migration to Unicode, so the above is expected. zlib itself doesn't care about whether the data to be encoded is text or bytes. In Python 3.x, it's probably better to use bytes throughout the API. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:14:40 2008 From: report at bugs.python.org (David M. Beazley) Date: Sat, 27 Dec 2008 13:14:40 +0000 Subject: [issue4758] Python 3.0 internet documentation needs work In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za> Message-ID: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za> New submission from David M. Beazley : I have recently completed a pretty thorough survey of library documentation for Python 3.0 in conjunction with an update I'm making to my book. This issue is not so much a bug as a documentation request. For all of the library modules related to network programming, it would be extremely useful to be much very explicit about what methods work with strings and what methods requires byte. So many of these modules operate on small fragments of data (e.g., send a request, add a header, parse a query string, etc.). Sometimes using a string is okay, sometimes it's not and sadly, it's not often predictable. Part of the problem is that the documentation has been written for a Python 2 world where text strings and binary data were interchangeable. Anyways, this request minimally covers these modules: ftplib smtplib nntplib http.* urllib.* xmlrpc.* socketserver asynchat asyncore If there is interest, I can submit more detailed notes from my own work, but I'm not sure how the documentation maintainer would want this. Separate issue for each? Added as comments here? Please advise. ---------- assignee: georg.brandl components: Documentation messages: 78361 nosy: beazley, georg.brandl severity: normal status: open title: Python 3.0 internet documentation needs work type: feature request versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:21:08 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 27 Dec 2008 13:21:08 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <49562BC1.5070709@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-26 22:09, Antoine Pitrou wrote: > This patch implements what is usually called "threaded code" for the > ceval loop on compilers which support it (only gcc). The idea is that > there is a separate opcode dispatch epilog at the end of each opcode, > which allows the CPU to make much better use of its branch prediction > capabilities. The net result is a 15-20% average speedup on pybench and > pystone, with higher speedups on very tight loops (see below for the > full pybench result chart). Now I know why you want opcode stats in pybench :-) This looks like a promising approach. Is is possible to backport this change to Python 2.x as well ? ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:27:21 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 13:27:21 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <49562BC1.5070709@egenix.com> Message-ID: <1230384442.10427.5.camel@localhost> Antoine Pitrou added the comment: > This looks like a promising approach. Is is possible to backport > this change to Python 2.x as well ? Certainly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:29:26 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 13:29:26 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230384566.83.0.269798714824.issue4753@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch uses a statically initialized jump table rather than specific initialization code. Added file: http://bugs.python.org/file12474/threadedceval2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:30:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 13:30:05 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230384605.79.0.206605400382.issue4753@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12457/threadedceval1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:58:23 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 13:58:23 +0000 Subject: [issue4757] reject unicode in zlib In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za> Message-ID: <1230386303.57.0.390922687682.issue4757@psf.upfronthosting.co.za> ebfe added the comment: I don't think Python 2.x should be changed - but 3.0 or 3.1 should be: - Characters don't mean a thing in zlib-land, all operations are based on bytes and their (implicit) default encoding. This behaviour is hidden and somewhat violates the rule of least surprise. - type(zlib.decompress(zlib.compress('abc'))) == bytes anyway - Changing from s* to y* forces the programmer to use .encode() on his strings (e.g. zlib.compress('abc'.encode()) which very clearly shows what's happening. If you want to compress and decompress Python3 strings, you *must* share the same character encoding; think of zlib.compress('h???') and str(zlib.decompress(x)) with different locales. - Other modules (hashlib comes to my mind...) already reject Unicode objects for the same argument. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 16:51:20 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 15:51:20 +0000 Subject: [issue4756] zipfile.is_zipfile: added support for file-like objects In-Reply-To: <1230356647.32.0.19774175032.issue4756@psf.upfronthosting.co.za> Message-ID: <1230393080.33.0.673574365418.issue4756@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed in r67946, r67947. Thanks! ---------- nosy: +pitrou resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 16:52:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 15:52:07 +0000 Subject: [issue4241] zipfile.py -> is_zipfile leaves file open when error In-Reply-To: <1225367525.69.0.93727529387.issue4241@psf.upfronthosting.co.za> Message-ID: <1230393127.06.0.684778973815.issue4241@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed by Gabriel's patch (just committed in trunk and py3k). ---------- nosy: +pitrou resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 17:10:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 16:10:32 +0000 Subject: [issue4745] socket.send obscure error message In-Reply-To: <1230169617.77.0.0806737582918.issue4745@psf.upfronthosting.co.za> Message-ID: <1230394232.65.0.970602440744.issue4745@psf.upfronthosting.co.za> Georg Brandl added the comment: Benjamin, please continue mentioning issue numbers in commit messages, even if it's a trivial fix like this one. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 17:39:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 16:39:12 +0000 Subject: [issue1194378] sendmsg() and recvmsg() for C socket module Message-ID: <1230395952.79.0.291419357167.issue1194378@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch doesn't apply cleanly to the current trunk (which is understandable, given the patch is from 2005). Also, some tests would be welcome as Thomas said. And bonus points for documentation :) ---------- nosy: +pitrou stage: -> needs patch type: -> feature request versions: +Python 2.7, Python 3.1 -Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 18:41:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 17:41:42 +0000 Subject: [issue4748] yield expression vs lambda In-Reply-To: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za> Message-ID: <1230399702.86.0.703825779946.issue4748@psf.upfronthosting.co.za> Georg Brandl added the comment: I didn't find it, but someone from the German Python webforum. :) Hmm, I wonder why lambda: (yield 1) alone doesn't give [1, None]. (That should also go into the test case.) Anyway, perhaps yield in lambdas should be forbidden. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 18:42:51 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 17:42:51 +0000 Subject: [issue4752] Error in SocketServer UDP documentation In-Reply-To: <1230325603.01.0.864584000034.issue4752@psf.upfronthosting.co.za> Message-ID: <1230399771.55.0.0580357693688.issue4752@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67952. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 18:55:45 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sat, 27 Dec 2008 17:55:45 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230400545.83.0.429742047624.issue4750@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Anatoly is right, the gzip file format specification (RFC 1952) says that the FNAME header field must be the basename of the original filename. So, this behaviour is not tarfile's fault but that of the gzip module and should be fixed there. 7zip can still decompress these files, right? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 19:07:41 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Dec 2008 18:07:41 +0000 Subject: [issue4748] yield expression vs lambda In-Reply-To: <1230399702.86.0.703825779946.issue4748@psf.upfronthosting.co.za> Message-ID: <1afaf6160812271007r52bbc247i351864e9a1b35103@mail.gmail.com> Benjamin Peterson added the comment: On Sat, Dec 27, 2008 at 11:41 AM, Georg Brandl wrote: > > Georg Brandl added the comment: > > I didn't find it, but someone from the German Python webforum. :) > > Hmm, I wonder why lambda: (yield 1) alone doesn't give [1, None]. (That > should also go into the test case.) Actually, I don't think the return value should even make it's way to the list. Generator lambdas shouldn't have any return value IMO. > > Anyway, perhaps yield in lambdas should be forbidden. Probably too late now for 2.x and 3.x. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 19:15:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 18:15:40 +0000 Subject: [issue4748] yield expression vs lambda In-Reply-To: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za> Message-ID: <1230401740.16.0.00666371405353.issue4748@psf.upfronthosting.co.za> Georg Brandl added the comment: >> Hmm, I wonder why lambda: (yield 1) alone doesn't give [1, None]. (That >> should also go into the test case.) > > Actually, I don't think the return value should even make it's way to > the list. Generator lambdas shouldn't have any return value IMO. Yes, I think so too. I just wondered at the seemingly inconsistent behavior right now. >> Anyway, perhaps yield in lambdas should be forbidden. > > Probably too late now for 2.x and 3.x. Right. I'd say go for applying the patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 19:20:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 18:20:44 +0000 Subject: [issue4739] [patch] Let users do help('@') and so on for confusing syntax constructs. In-Reply-To: <1230140265.88.0.991018728121.issue4739@psf.upfronthosting.co.za> Message-ID: <1230402044.43.0.843859558733.issue4739@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the patch! Applied with minor edits to the trunk as r67953. I will backport to the 2.6 branch as well. ---------- resolution: -> accepted status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 19:22:24 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 18:22:24 +0000 Subject: [issue4758] Python 3.0 internet documentation needs work In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za> Message-ID: <1230402144.02.0.195915582997.issue4758@psf.upfronthosting.co.za> Georg Brandl added the comment: I'd be happy with comments on this bug. I can't promise that I'll have the time to review everything, but the more specific the remarks are, the easier it's for me to update the docs. Thanks for your efforts! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 19:24:30 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Dec 2008 18:24:30 +0000 Subject: [issue4748] yield expression vs lambda In-Reply-To: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za> Message-ID: <1230402270.69.0.624959286933.issue4748@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r67954. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 19:49:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 18:49:32 +0000 Subject: [issue4754] winsound documentation (about stoping sounds) In-Reply-To: <1230331746.17.0.591336113969.issue4754@psf.upfronthosting.co.za> Message-ID: <1230403772.65.0.970192968254.issue4754@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, applied in r67957. ---------- resolution: -> accepted status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 20:03:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 19:03:08 +0000 Subject: [issue4682] 'b' formatter is actually unsigned char In-Reply-To: <1229511739.0.0.626057427861.issue4682@psf.upfronthosting.co.za> Message-ID: <1230404588.07.0.914742135802.issue4682@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed the docs in r67958. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 20:04:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 19:04:54 +0000 Subject: [issue4695] Bad AF_PIPE address in multiprocessing documentation In-Reply-To: <1229633609.42.0.990434424084.issue4695@psf.upfronthosting.co.za> Message-ID: <1230404694.45.0.977425386249.issue4695@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67960. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 20:08:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 19:08:22 +0000 Subject: [issue4697] Clarification needed for subprocess convenience functions in Python 3.0 documentation In-Reply-To: <1229639926.42.0.148346295648.issue4697@psf.upfronthosting.co.za> Message-ID: <1230404902.5.0.84478282501.issue4697@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r67962. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 20:11:31 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 19:11:31 +0000 Subject: [issue4671] pydoc executes the code to be documented In-Reply-To: <1229376434.19.0.800052631244.issue4671@psf.upfronthosting.co.za> Message-ID: <1230405091.76.0.209129651314.issue4671@psf.upfronthosting.co.za> Georg Brandl added the comment: Documented in r67963. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 20:13:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 19:13:02 +0000 Subject: [issue4669] bytes,join and bytearray.join not in manual; help for bytes.join is wrong. In-Reply-To: <1229329784.58.0.84286765915.issue4669@psf.upfronthosting.co.za> Message-ID: <1230405182.06.0.392397224417.issue4669@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as "works for me". ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 21:26:16 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 20:26:16 +0000 Subject: [issue4732] Object allocation stress leads to segfault on RHEL In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> Message-ID: <1230409576.51.0.611437450224.issue4732@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I can't reproduce it under Mandriva Linux on an x86-64 machine. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 21:40:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 20:40:05 +0000 Subject: [issue4677] a list comprehensions tests for pybench In-Reply-To: <1229465960.59.0.848969060815.issue4677@psf.upfronthosting.co.za> Message-ID: <1230410405.28.0.493480042344.issue4677@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed (r67965, r67966). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 21:56:22 2008 From: report at bugs.python.org (ebfe) Date: Sat, 27 Dec 2008 20:56:22 +0000 Subject: [issue4732] Object allocation stress leads to segfault on RHEL In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> Message-ID: <1230411382.08.0.489430072018.issue4732@psf.upfronthosting.co.za> ebfe added the comment: I can't reproduce the problem here. Python 2.5.2 running on Linux lueg-desktop 2.6.24-22-generic #1 SMP Mon Nov 24 18:32:42 UTC 2008 i686 GNU/Linux ---------- nosy: +ebfe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 22:05:37 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 21:05:37 +0000 Subject: [issue4444] unittest - use contexts to assert exceptions In-Reply-To: <1227779400.76.0.0502987149884.issue4444@psf.upfronthosting.co.za> Message-ID: <1230411937.37.0.916173160972.issue4444@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 23:49:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 22:49:42 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1230418182.76.0.775942268801.issue4705@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch nosy: +pitrou priority: -> high stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file12475/unbufferedstdout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 00:07:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 23:07:56 +0000 Subject: [issue4270] struct module: pack/unpack and byte order on x86_64 In-Reply-To: <1225992644.3.0.448967011031.issue4270@psf.upfronthosting.co.za> Message-ID: <1230419276.71.0.0258523909713.issue4270@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The change in result length is actually normal. If you look at the doc for the struct module, the default size and byte order character is "@", which means "native byte order and native size". On x86-64 Linux, the "native" long size is 64 bits, so the result is 8 bytes long. When using one of {"<", ">", "!", "="}, you instead select the "standard" long size according to the struct module which is 32 bits. I agree it can be surprising though. ---------- nosy: +pitrou resolution: -> invalid status: open -> closed versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 00:09:27 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 23:09:27 +0000 Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za> Message-ID: <1230419367.04.0.989821546431.issue4265@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou priority: -> normal stage: -> patch review versions: +Python 2.7, Python 3.1 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 00:13:24 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 23:13:24 +0000 Subject: [issue3055] test_list on 64-bit platforms In-Reply-To: <1212788254.95.0.00817873629987.issue3055@psf.upfronthosting.co.za> Message-ID: <1230419604.59.0.0723191616905.issue3055@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 00:23:11 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 23:23:11 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230420191.76.0.615568499321.issue4489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What course of action do you suggest? First chmod 0700 on the directory? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 00:28:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Dec 2008 23:28:52 +0000 Subject: [issue4759] bytearray.translate() should support None first argument In-Reply-To: <1230420531.87.0.593761849441.issue4759@psf.upfronthosting.co.za> Message-ID: <1230420531.87.0.593761849441.issue4759@psf.upfronthosting.co.za> New submission from Georg Brandl : bytes.translate() does. Patch attached. ---------- assignee: pitrou components: Interpreter Core files: bytearray-translate.diff keywords: patch messages: 78390 nosy: georg.brandl, pitrou priority: normal severity: normal stage: patch review status: open title: bytearray.translate() should support None first argument type: behavior versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12476/bytearray-translate.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 00:31:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2008 23:31:56 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230420716.0.0.341972724292.issue4489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Mmmh, very recent Linux kernels (>= 2.6.16) seem to have specific functions to deal with this (see man pages for openat, unlinkat, etc.). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 02:06:13 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 28 Dec 2008 01:06:13 +0000 Subject: [issue4759] bytearray.translate() should support None first argument In-Reply-To: <1230420531.87.0.593761849441.issue4759@psf.upfronthosting.co.za> Message-ID: <1230426373.11.0.98787144402.issue4759@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Looks good to me. I don't think it should be applied to 3.0, though. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 02:23:51 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 01:23:51 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1230427431.01.0.919334227667.issue4705@psf.upfronthosting.co.za> STINNER Victor added the comment: pitrou's patch changes PyFile_FromFd() behaviour for a text file opened with buffering=0: /* As a convenience, when buffering == 0 on a text file, we open the underlying binary stream in unbuffered mode and wrap it with a text stream in line-buffered mode. */ Why changing PyFile_FromFd() and not io.open() directly? Note: I prefer Py_UnbufferedStdoutFlag=1 instead of Py_UnbufferedStdoutFlag++ (for -u command line option). Except the minor comments, I like the patch (and it has unit tests!) ;-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 04:56:47 2008 From: report at bugs.python.org (David W. Lambert) Date: Sun, 28 Dec 2008 03:56:47 +0000 Subject: [issue4760] cmp gone---What's new in 3.1 In-Reply-To: <1230436607.02.0.835606741355.issue4760@psf.upfronthosting.co.za> Message-ID: <1230436607.02.0.835606741355.issue4760@psf.upfronthosting.co.za> New submission from David W. Lambert : http://docs.python.org/dev/3.0/whatsnew/3.1.html To Other Language Changes add cmp removed. I haven't installed version 3.1; I don't know if it has actually been removed. ---------- assignee: georg.brandl components: Documentation messages: 78394 nosy: LambertDW, georg.brandl severity: normal status: open title: cmp gone---What's new in 3.1 versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 11:27:50 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 10:27:50 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1230427431.01.0.919334227667.issue4705@psf.upfronthosting.co.za> Message-ID: <1230460069.6361.3.camel@localhost> Antoine Pitrou added the comment: > pitrou's patch changes PyFile_FromFd() behaviour for a text file > opened with buffering=0: > /* As a convenience, when buffering == 0 on a text file, we > open the underlying binary stream in unbuffered mode and > wrap it with a text stream in line-buffered mode. */ > > Why changing PyFile_FromFd() and not io.open() directly? I must admit I'm a bit lazy, and changing io.open() means changing a fundamental public API, as Guido said on python-dev, so more discussion and some parts of the patches delayed to 3.1. If someone else wants to do it, please don't hesitate... > Note: I prefer Py_UnbufferedStdoutFlag=1 instead of > Py_UnbufferedStdoutFlag++ (for -u command line option). Well, I minimally changed the existing code. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 11:40:48 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 10:40:48 +0000 Subject: [issue4759] bytearray.translate() should support None first argument In-Reply-To: <1230420531.87.0.593761849441.issue4759@psf.upfronthosting.co.za> Message-ID: <1230460848.14.0.336544466435.issue4759@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks like there's a problem: >>> bytearray().translate(None, None) Traceback (most recent call last): File "", line 1, in TypeError: Type NoneType doesn't support the buffer API >>> bytearray().translate(None, None) Erreur de segmentation Also, the patch should probably be backported to trunk. ---------- versions: +Python 2.7 -Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 12:55:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 28 Dec 2008 11:55:42 +0000 Subject: [issue4759] bytearray.translate() should support None first argument In-Reply-To: <1230420531.87.0.593761849441.issue4759@psf.upfronthosting.co.za> Message-ID: <1230465342.45.0.57769951355.issue4759@psf.upfronthosting.co.za> Georg Brandl added the comment: You're right (but the segfault isn't introduced by the patch). Fixed segfault in 3.0 and 2.6 in r67975 and r67977. Applied path in 3k and trunk in r67974 and r67976. ---------- assignee: pitrou -> georg.brandl resolution: -> accepted status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 12:56:32 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Sun, 28 Dec 2008 11:56:32 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230465392.14.0.798229636494.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: A shameless copy of the Perl fix for the bug http://bugs.debian.org/286922 looks like the evident solution. Somebody has to examine the fix though, I'm afraid I'm not currently able to do it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 12:59:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 28 Dec 2008 11:59:13 +0000 Subject: [issue4731] suggest change to "Failed to find the necessary bits to build these modules" message In-Reply-To: <1230056496.59.0.297027994957.issue4731@psf.upfronthosting.co.za> Message-ID: <1230465553.28.0.216103215788.issue4731@psf.upfronthosting.co.za> Georg Brandl added the comment: Done in r67978. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 13:19:19 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 12:19:19 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1230466759.43.0.978356783426.issue4705@psf.upfronthosting.co.za> STINNER Victor added the comment: > > Why changing PyFile_FromFd() and not io.open() directly? > > I must admit I'm a bit lazy, and changing io.open() means changing > a fundamental public API, as Guido said on python-dev, so > more discussion and some parts of the patches delayed to 3.1. You're right, and PyFile_FromFd() is also a fundamental "public" API. Since TextIOWrapper doesn't support real unbuffered buffer (only pseudo line buffer: unbuffered raw buffer and line buffering for TextIOWrapper), I prefer to change only stdout/stderr instead of PyFile_FromFd(). My new patch only changes initstdio() using pitrou's code. Should we also change stdin? Added file: http://bugs.python.org/file12477/unbufferedstdout-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 13:28:29 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Dec 2008 12:28:29 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1230467309.08.0.337457388695.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: enumerate can be added to the list of builtin types which isn't initialised correctly, as can the callable+sentinel iterator return from the 2-argument version of iter() and the default sequence iterator returned by iter() when given a type with both __len__ and __getitem__ methods, but no __iter__ method. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 13:46:58 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Dec 2008 12:46:58 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1230468418.36.0.264447464842.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: Copied from python-dev post: Perhaps the path of least resistance is to change PyObject_Hash to be yet another place where PyType_Ready will be called implicitly if it hasn't been called already? That approach would get us back to the Python 2.x status quo where calling PyType_Ready was only absolutely essential if you wanted to correctly inherit a slot from a type other than object itself. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 14:54:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 13:54:04 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1230466759.43.0.978356783426.issue4705@psf.upfronthosting.co.za> Message-ID: <1230472445.6361.33.camel@localhost> Antoine Pitrou added the comment: Le dimanche 28 d?cembre 2008 ? 12:19 +0000, STINNER Victor a ?crit : > STINNER Victor added the comment: > > > > Why changing PyFile_FromFd() and not io.open() directly? > > > > I must admit I'm a bit lazy, and changing io.open() means changing > > a fundamental public API, as Guido said on python-dev, so > > more discussion and some parts of the patches delayed to 3.1. > > You're right, and PyFile_FromFd() is also a fundamental "public" API. Well, open() is fundamental as in part of the built-ins and used pervasively. PyFile_FromFd(), on the other hand, is a relic of the 2.x C file handling API. Let's see what others have to say about this. > Should we also change stdin? I don't know, but "python -h" only talks about stderr/stdout. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 15:29:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 14:29:39 +0000 Subject: [issue4444] unittest - use contexts to assert exceptions In-Reply-To: <1227779400.76.0.0502987149884.issue4444@psf.upfronthosting.co.za> Message-ID: <1230474579.67.0.91483112036.issue4444@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed an improved patch, with tests and doc, in r67979 and r67981. Thanks! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 15:38:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 14:38:40 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230475120.13.0.367440539746.issue4489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The Perl patch is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=36;filename=etch_03_fix_file_path;att=1;bug=286922 It is a recursive implementation of rmtree. What it does is 1) get the inode of the path 2) unlink it altogether if not a dir 3) otherwise, chdir to it 4) check that '.' still has the same inode, otherwise bail out. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 15:49:48 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 14:49:48 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230475788.76.0.736978868703.issue4489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Mmmh, the problem with Perl's approach is that it changes the current working directory (calls to chdir()), which is process-specific and not thread-specific. Currently, no function in shutil changes the current working directory, which is a nice behaviour and should IMO be preserved. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 15:58:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 14:58:39 +0000 Subject: [issue4761] create Python wrappers for openat() and others In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za> Message-ID: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Very recent POSIX versions have introduced a set of functions named openat(), unlinkat(), etc. (*) which allow to access files relatively to a directory pointed to by a file descriptor (rather than the process-wide current working directory). They are necessary to implement thread-safe directory traversal without any symlink attacks such as in #4489. Providing Python wrappers for these functions would help creating higher-level abstractions for secure directory traversal on platforms that support it. (*) http://www.opengroup.org/onlinepubs/9699919799/functions/openat.html ?The purpose of the openat() function is to enable opening files in directories other than the current working directory without exposure to race conditions. Any part of the path of a file could be changed in parallel to a call to open(), resulting in unspecified behavior. By opening a file descriptor for the target directory and using the openat() function it can be guaranteed that the opened file is located relative to the desired directory.? ---------- components: Extension Modules, Library (Lib) messages: 78407 nosy: loewis, pitrou priority: normal severity: normal status: open title: create Python wrappers for openat() and others type: feature request versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 16:11:10 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 15:11:10 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1230477070.13.0.893775469046.issue4705@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It seems the "name" field of the TextIOWrapper object isn't set in create_stdio() (the "char *name" parameter isn't used). Otherwise, the patch looks good. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 16:30:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 15:30:56 +0000 Subject: [issue1034053] unittest.py patch: add skipped test functionality Message-ID: <1230478256.91.0.380267564279.issue1034053@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Pupeno's patch looks good to me. Additional candy would be a decorator to flag skipped tests (e.g. @skipped_test or @skipped_test("A message")), but we can do that later. ---------- stage: -> patch review type: -> feature request versions: +Python 2.7, Python 3.1 -Python 2.4, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 16:36:17 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 15:36:17 +0000 Subject: [issue2153] unittest.py modernization In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za> Message-ID: <1230478577.54.0.249022043846.issue2153@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Will take a look. ---------- versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 16:37:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 15:37:04 +0000 Subject: [issue4034] traceback attribute error In-Reply-To: <1223076719.45.0.395696576555.issue4034@psf.upfronthosting.co.za> Message-ID: <1230478624.09.0.136178775578.issue4034@psf.upfronthosting.co.za> Antoine Pitrou added the comment: One possibility would be to only allow deleting the tb_frame attribute (setting it to NULL), not setting it to an arbitrary object. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 16:38:01 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 28 Dec 2008 15:38:01 +0000 Subject: [issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC In-Reply-To: <1223332030.39.0.313145041612.issue4060@psf.upfronthosting.co.za> Message-ID: <1230478681.65.0.836462816962.issue4060@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Applied the patch in r67982. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 16:38:44 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 28 Dec 2008 15:38:44 +0000 Subject: [issue4728] Endianness and universal builds problems In-Reply-To: <1230004796.26.0.433339643882.issue4728@psf.upfronthosting.co.za> Message-ID: <1230478724.99.0.561118297579.issue4728@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I applied the patch for #4060 in r67982. I would still like to know what difference an Intel machine makes in the installers, though. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 16:46:31 2008 From: report at bugs.python.org (anatoly techtonik) Date: Sun, 28 Dec 2008 15:46:31 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230479191.33.0.70683116109.issue4750@psf.upfronthosting.co.za> anatoly techtonik added the comment: 7zip can decompress both, but it still creates "dist/" directory when decompressing file that is made with Python. I've noticed this bug with extra path component is actual with "tar" + "gzip" under windows. If they are executed separately and windows path with backslashes is used - directory prefix is not stripped. I.e. this creates archive with invalid header: {{{ tar -cf dist\create_tar_sep.tar package gzip -f9 dist\create_tar_sep.tar }}} This command is ok: {{{ tar -cf dist\create_tar_sep.tar package gzip -f9 dist/create_tar_sep.tar }}} _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:01:50 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 16:01:50 +0000 Subject: [issue2153] unittest.py modernization In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za> Message-ID: <1230480110.26.0.740739392633.issue2153@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed in r67985, thanks! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:03:19 2008 From: report at bugs.python.org (Jakub Wilk) Date: Sun, 28 Dec 2008 16:03:19 +0000 Subject: [issue4608] urllib.request.urlopen does not return an iterable object In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za> Message-ID: <1230480199.49.0.878998350671.issue4608@psf.upfronthosting.co.za> Jakub Wilk added the comment: Regarding Senthil's patch: __next__() method seems superfluous to me (and the implementation is buggy). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:04:52 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 16:04:52 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1230480292.83.0.263008090393.issue4705@psf.upfronthosting.co.za> STINNER Victor added the comment: >> Should we also change stdin? > I don't know, but "python -h" only talks about stderr/stdout. The manpage of Python2 is clear: -u Force stdin, stdout and stderr to be totally unbuffered. stdin is also unbuffered. > It seems the "name" field of the TextIOWrapper object isn't > set in create_stdio() It used only used for buffered output. Without the patch, sys.stdout.name == sys.stdout.buffer.name == '1' :-/ New patch: - use create_stdio() to create unbuffered sys.stdin - rename Py_UnbufferedStdoutFlag to Py_UnbufferedStdioFlag - replace "Py_UnbufferedStdioFlag++;" by "Py_UnbufferedStdioFlag = 1;" - change create_stdio(): (...) Note: there is no test for unbuffered input because I don't know how to test this (even by manual tests) :-p Added file: http://bugs.python.org/file12478/unbufferedstdout-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:38:35 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Sun, 28 Dec 2008 16:38:35 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230482315.85.0.29725439028.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: > Mmmh, the problem with Perl's approach is that it changes the current > working directory (calls to chdir()), which is process-specific and not > thread-specific. Currently, no function in shutil changes the current > working directory, which is a nice behaviour and should IMO be preserved. Using chdir() makes sense and it doesn't look like a too big problem to me: def rmtree(...): ... curdir = os.getcwd() try: call chdir() as required finally: try: os.chdir(curdir) except: warnings.warn("Unable to chdir to previous current dir") ... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:57:10 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 16:57:10 +0000 Subject: [issue4762] PyFile_FromFd() doesn't set the file name In-Reply-To: <1230483429.96.0.00901303311895.issue4762@psf.upfronthosting.co.za> Message-ID: <1230483429.96.0.00901303311895.issue4762@psf.upfronthosting.co.za> New submission from STINNER Victor : PyFile_FromFd() never changes the name of new created file object: $ ./python -c "import sys; print(sys.stdout.buffer.name, sys.stdout.name)" 0 0 Expected result: . --- Binary mode: - with buffering == 0, the file object is a FileIO. Changing the name can be done with: file._name=new_name - with buffering != 0, the file object is a BufferedXXX() and file.raw is a FileIO. So we have to set: file.raw._name=new_name If text mode, the file object is a TextIOWrapper and file.raw is a BufferedXXX() (buffering=0 is forbidden for text file). So changing the name can be done with: file.raw.raw._name=newname. I'm not sure of the classes/types. Note: PyFile_FromFd() shouldn't use PyErr_Clear() if changing the name fails. ---------- components: None messages: 78419 nosy: haypo severity: normal status: open title: PyFile_FromFd() doesn't set the file name type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:57:48 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 16:57:48 +0000 Subject: [issue4705] python3.0 -u: unbuffered stdout In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za> Message-ID: <1230483468.8.0.916460309218.issue4705@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached: quick and dirty test to check if the standard input is buffered or not. My short test program works with python2.5 and py3k trunk without the -u command line option. So changing sys.stdin buffer is not really important. About the wrong name, I opened a separated issue: #4762, PyFile_FromFd() doesn't set the file name. Added file: http://bugs.python.org/file12479/test_stdin.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 18:05:10 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 17:05:10 +0000 Subject: [issue4762] PyFile_FromFd() doesn't set the file name In-Reply-To: <1230483429.96.0.00901303311895.issue4762@psf.upfronthosting.co.za> Message-ID: <1230483910.01.0.94876871379.issue4762@psf.upfronthosting.co.za> STINNER Victor added the comment: In my last patch to fix the issue #4705, I replaced PyFile_FromFd() by custom code which set correctly the file name. PyFile_FromFd() is also used in: - _Py_DisplaySourceLine(): name is not used, only PyFile_GetLine(file) - call_find_module() (imp.find_module()): return the file object with the wrong name Example with imp: >>> file, filename, extra = imp.find_module("os") >>> file >>> file.name 4 >>> filename '/home/SHARE/SVN/py3k/Lib/os.py' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 18:06:35 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 17:06:35 +0000 Subject: [issue4762] PyFile_FromFd() doesn't set the file name In-Reply-To: <1230483429.96.0.00901303311895.issue4762@psf.upfronthosting.co.za> Message-ID: <1230483995.81.0.600228869352.issue4762@psf.upfronthosting.co.za> STINNER Victor added the comment: > In my last patch to fix the issue #4705, I replaced PyFile_FromFd() > by custom code which set correctly the file name. The standard I/O: sys.stdin, sys.stdout and sys.stderr. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 18:06:58 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2008 17:06:58 +0000 Subject: [issue4762] PyFile_FromFd() doesn't set the file name In-Reply-To: <1230483429.96.0.00901303311895.issue4762@psf.upfronthosting.co.za> Message-ID: <1230484018.51.0.633856000333.issue4762@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 18:33:20 2008 From: report at bugs.python.org (Eric Smith) Date: Sun, 28 Dec 2008 17:33:20 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1230485600.5.0.656149882555.issue4701@psf.upfronthosting.co.za> Eric Smith added the comment: > Perhaps the path of least resistance is to change PyObject_Hash to be > yet another place where PyType_Ready will be called implicitly if it > hasn't been called already? I think that's the best thing to do. It would bring PyObject_Hash in line with PyObject_Format, for example. If we pick some other solution (instead of modifying PyObject_Hash), then we should find all of the lazy calls to PyType_Ready (that exist to solve this problem) and remove them. IOW, it should be handled the same everywhere. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 19:43:05 2008 From: report at bugs.python.org (Remy Blank) Date: Sun, 28 Dec 2008 18:43:05 +0000 Subject: [issue1034053] unittest.py patch: add skipped test functionality Message-ID: <1230489785.24.0.532192367416.issue1034053@psf.upfronthosting.co.za> Remy Blank added the comment: There's still a typo in the docstring of TestResult.addSkipped() (tuble -> tuple). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 20:07:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 19:07:15 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1230482315.85.0.29725439028.issue4489@psf.upfronthosting.co.za> Message-ID: <1230491235.6361.37.camel@localhost> Antoine Pitrou added the comment: > Using chdir() makes sense and it doesn't look like a too big problem to me: It's a problem if another thread in the process is making file operations using relative paths at the same time. Since shutil functions have until now been safe against this possibility, I don't think it's ok to make them unsafe in future versions. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 20:08:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2008 19:08:56 +0000 Subject: [issue3700] test_bigmem broken In-Reply-To: <1219842927.03.0.0279927049136.issue3700@psf.upfronthosting.co.za> Message-ID: <1230491336.77.0.294531654867.issue3700@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. Not only does it fix the str tests, but it also adds similar tests for bytes and bytearray objects. ---------- keywords: +patch stage: -> patch review versions: +Python 3.1 Added file: http://bugs.python.org/file12480/bigmemtest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 20:40:10 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 28 Dec 2008 19:40:10 +0000 Subject: [issue4728] Endianness and universal builds problems In-Reply-To: <1230478724.99.0.561118297579.issue4728@psf.upfronthosting.co.za> Message-ID: <8D2DBC73-1AC1-4FAE-A2B6-BA40E93E3D17@mac.com> Ronald Oussoren added the comment: On 28 Dec, 2008, at 16:38, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > I applied the patch for #4060 in r67982. I've backported that to 2.6-maint in r67987. > > > I would still like to know what difference an Intel machine makes in > the > installers, though. It should make no difference at all. I haven't tested building on a PPC machine though, all 2.5.x installers were build on an intel box because that happens to be my main development machine. A nice side- effect of building on an intel box is that you can test both architectures without switching to another machine (through Rosetta). Ronald Added file: http://bugs.python.org/file12481/smime.p7s _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From report at bugs.python.org Sun Dec 28 20:52:40 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 28 Dec 2008 19:52:40 +0000 Subject: [issue4064] distutils.util.get_platform() is wrong for universal builds on macosx In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za> Message-ID: <1230493960.1.0.896356127667.issue4064@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I've committed the patch with some documentation in r67988, with a backport to 2.6.x in r67989. r67990 (not backported) is a minor update of the patch, it adds explicit support code for all three variants that are configurable through the configure script. I don't think it is useful to worry about architectures that are not supported by current releases of MacOSX. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 21:13:28 2008 From: report at bugs.python.org (garcia) Date: Sun, 28 Dec 2008 20:13:28 +0000 Subject: [issue4763] PyErr_GivenExceptionMatches documentation out of date In-Reply-To: <1230495208.55.0.311096414507.issue4763@psf.upfronthosting.co.za> Message-ID: <1230495208.55.0.311096414507.issue4763@psf.upfronthosting.co.za> New submission from garcia : The documentation for PyErr_GivenExceptionMatches states that "If given is NULL, a memory access violation will occur." However, looking at the code, this is not the case: the function returns 0 (read: false). It appears, rather, that this function always succeeds. ---------- assignee: georg.brandl components: Documentation messages: 78429 nosy: garcia, georg.brandl severity: normal status: open title: PyErr_GivenExceptionMatches documentation out of date versions: Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 21:26:07 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 28 Dec 2008 20:26:07 +0000 Subject: [issue4761] create Python wrappers for openat() and others In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za> Message-ID: <1230495967.44.0.897634752404.issue4761@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There is a tradition that any POSIX calls are added to the POSIX module without much discussion, provided that a) there is an autoconf test testing for their presence, and b) they expose the API as-is, i.e. without second-guessing the designers of the original API. So contributions are welcome. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 21:54:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 28 Dec 2008 20:54:41 +0000 Subject: [issue4761] create Python wrappers for openat() and others In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za> Message-ID: <1230497681.12.0.372405794228.issue4761@psf.upfronthosting.co.za> Christian Heimes added the comment: The openat() functions sound useful indeed. However I'm concerned about the file descriptor requirment for the *at() POSIX functions. In Python file descriptors can lead to resource leaks because developers are used to automatic garbage collection. os.open() is the only way to get a file descriptor to a directory. The builtin open() doesn't open directories. Developers may think that the file descriptor is closed when the integer object gets out of scope. I propose the addition of opendir() for the purpose of the *at() functions. The opendir function should return a wrapper object around the DIR* pointer returned by opendir(). A function fileno() exposed the file descriptor of the DIR pointer via dirfd(). ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 22:16:26 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 28 Dec 2008 21:16:26 +0000 Subject: [issue4763] PyErr_GivenExceptionMatches documentation out of date In-Reply-To: <1230495208.55.0.311096414507.issue4763@psf.upfronthosting.co.za> Message-ID: <1230498986.99.0.143799283452.issue4763@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the report! Fixed in r67995. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 22:17:30 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 28 Dec 2008 21:17:30 +0000 Subject: [issue4761] create Python wrappers for openat() and others In-Reply-To: <1230497681.12.0.372405794228.issue4761@psf.upfronthosting.co.za> Message-ID: <4957ECE6.9010106@v.loewis.de> Martin v. L?wis added the comment: > Developers may think that the file descriptor is closed when the integer > object gets out of scope. I'm not concerned about that. When they use os.open, they will typically understand what a file handle is, and how it relates to > I propose the addition of opendir() for the purpose of the *at() > functions. The opendir function should return a wrapper object around > the DIR* pointer returned by opendir(). A function fileno() exposed the > file descriptor of the DIR pointer via dirfd(). -1. This is exactly the second-guessing kind of thing that the POSIX module should avoid. openat(2) doesn't expect DIR objects, and neither should posix.openat. If desired, a layer can be added on top of this that makes it more "safe", e.g. in the os module; such a layer should then try to make it cross-platform before trying to make it safe. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 22:28:22 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 28 Dec 2008 21:28:22 +0000 Subject: [issue4617] SyntaxError when free variable name is also an exception target In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za> Message-ID: <1230499702.42.0.614876675883.issue4617@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think being able to delete free variables is reasonable and brings more consistency as well as solving corner cases like this. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 23:32:54 2008 From: report at bugs.python.org (anatoly techtonik) Date: Sun, 28 Dec 2008 22:32:54 +0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1230503574.51.0.319173512792.issue1886@psf.upfronthosting.co.za> anatoly techtonik added the comment: Roumen, could you be more specific about what are you trying to say with this 200kB piece of code? Was it the intention to post a link to man or another piece of spec? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 23:37:20 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 28 Dec 2008 22:37:20 +0000 Subject: [issue4685] IDLE will not open (2.6.1 on WinXP pro) In-Reply-To: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za> Message-ID: <1230503840.65.0.326093737413.issue4685@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I would like to see the complete list of messages. Looks like a broken python installation... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 23:44:45 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 28 Dec 2008 22:44:45 +0000 Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za> Message-ID: <1230504285.8.0.71268701667.issue4449@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 02:03:55 2008 From: report at bugs.python.org (Jan Kaliszewski) Date: Mon, 29 Dec 2008 01:03:55 +0000 Subject: [issue4764] open('existing_dir') -> IOError instance's attr filename is None In-Reply-To: <1230512634.5.0.564476088999.issue4764@psf.upfronthosting.co.za> Message-ID: <1230512634.5.0.564476088999.issue4764@psf.upfronthosting.co.za> New submission from Jan Kaliszewski : Py2.4 and 2.5 (and probably other 2.x releases too): >>> try: f=open('existing_dir') ... except IOError, exc: print exc.filename ... None (expected result: "existing_dir") Py3.0 (and possibly 3.1 too): >>> try: f=open('existing_dir') ... except IOError as exc: print(exc.filename) ... None (expected result: "existing_dir") But no problems with: open('existing_dir', 'w') => exc.filename=='existing_dir' open('not_existing_file') => exc.filename=='not_existing_file' Guess: It may be similar to issue #599163 Platform/system info: [GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2 Linux 2.6.25-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz * Py2.4 == Python 2.4.4 (#1, Oct 7 2008, 13:16:18) * Py2.5 == Python 2.5.2 (r252:60911, Sep 15 2008, 12:11:51) * Py3.0 == Python 3.0 (r30:67503, Dec 29 2008, 01:15:48) ---------- components: Library (Lib) messages: 78437 nosy: zuo severity: normal status: open title: open('existing_dir') -> IOError instance's attr filename is None type: behavior versions: Python 2.4, Python 2.5, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 05:11:40 2008 From: report at bugs.python.org (Andrew) Date: Mon, 29 Dec 2008 04:11:40 +0000 Subject: [issue4732] Object allocation stress leads to segfault on RHEL In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> Message-ID: <1230523900.83.0.652637216345.issue4732@psf.upfronthosting.co.za> Andrew added the comment: Cannot reproduce this on RHEL 4. So far only RHEL 5.x seems to be affected. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 05:38:40 2008 From: report at bugs.python.org (Alex Fainshtein) Date: Mon, 29 Dec 2008 04:38:40 +0000 Subject: [issue4765] IDLE fails to "Delete Custom Key Set" properly In-Reply-To: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za> Message-ID: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za> New submission from Alex Fainshtein : How to reproduce: 1. Start IDLE -> "Python Shell" window opens. 2. Open Options|"Configure Idle...". 3. In "idle" dialog select "Keys" tab. 4. Click "Set as New Custom Key Set" button. 5 In "New Custom Key Set" dialog, type a name, click "Ok". 4. Click "Apply". Then notice that in the folder C:\Documents and Settings\\.idlerc, two new files appear, config-keys.cfg and config-main.cfg. The contents of the latter is [Keys] default = 0 name = SO FAR ALL IS OK. 5. Now go back to "idle" dialog, click "Delete Custom Key Set", then "Apply". Notice that config-keys.cfg file disappeared, but config-main.cfg neither disappeared nor changed. My guess, THIS IS THE BUG. 6. Now click "Ok" - no reaction. Click "Cancel" - crash: the Python windows disappear. Try to restart IDLE - it WOULD NOT START until config-main.cfg is manually deleted. ---------- components: IDLE messages: 78439 nosy: alex_fainshtein severity: normal status: open title: IDLE fails to "Delete Custom Key Set" properly type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 09:22:56 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 08:22:56 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230538976.74.0.800568236031.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: Ah, right you are. Attaching an initial alpha-quality patched shutil.py and a script to test the attack. Run the script by sourcing it with . test_issue4489.sh, not by executing (job control won't work in this case). Added file: http://bugs.python.org/file12482/shutil_patched.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 09:23:14 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 08:23:14 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230538994.75.0.723651307695.issue4489@psf.upfronthosting.co.za> Changes by Mart S?mermaa : Added file: http://bugs.python.org/file12483/test_issue4489.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 09:30:41 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 08:30:41 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230539441.47.0.0286052569787.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: And here's the diff so you can review what I was up to. Note that this does not yet fix the problem (although the logic looks about right), I have to examine the problem more thoroughly. ---------- keywords: +patch Added file: http://bugs.python.org/file12484/issue4489_first_attempt.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 09:41:51 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 08:41:51 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230540111.7.0.0240777467539.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: Aha, got it -- while removing /a/b/c/d, there's no easy way to detect that b or c has become a symlink. I.e. given directory tree a `-- b |-- c `-- d 1. os.rmdir('/a/b/c') succeeds 2. execution is suspended 3. '/a/b' is made a symlink to a path that contains 'd' 4. '/a/b/d' is neither a symlink, nor has it's inode been recorded, so os.rmdir('/a/b/d') succeeds I'm afraid the solution for the Perl bug is susceptible to the same problem. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 09:46:05 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 08:46:05 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230540365.94.0.963262339481.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: A blunt, ineffective solution would be to walk the tree before removing it and recording path : inode pairs in a dict on first pass and then checking that the inodes have not changed during removal on second pass. If no clever bulletproof fix emerges, perhaps this should be added as shutil.rmtree_safe (duh, API bloat...)? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 10:48:31 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 29 Dec 2008 09:48:31 +0000 Subject: [issue3671] What's New in 2.6 - corrections In-Reply-To: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za> Message-ID: <1230544111.44.0.725929155935.issue3671@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 10:49:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 29 Dec 2008 09:49:07 +0000 Subject: [issue3644] ``make htmlview`` for docs fails on OS X In-Reply-To: <1219376217.3.0.964627444856.issue3644@psf.upfronthosting.co.za> Message-ID: <1230544147.41.0.986339180912.issue3644@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 11:05:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 29 Dec 2008 10:05:05 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1230540365.94.0.963262339481.issue4489@psf.upfronthosting.co.za> Message-ID: <1230545107.10188.1.camel@localhost> Antoine Pitrou added the comment: > A blunt, ineffective solution would be to walk the tree before removing > it and recording path : inode pairs in a dict on first pass and then > checking that the inodes have not changed during removal on second pass. There's no way to do the "check inode then remove" sequence atomically. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 12:13:35 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 11:13:35 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230549215.71.0.751908568625.issue4489@psf.upfronthosting.co.za> Changes by Mart S?mermaa : Removed file: http://bugs.python.org/file12483/test_issue4489.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 12:15:03 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 11:15:03 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230549303.29.0.938002233984.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: Fixed a minor bug in test script and added Perl test as well. Perl with File-Path-2.07 passes the test. Added file: http://bugs.python.org/file12485/test_issue4489.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 12:19:21 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 11:19:21 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230549561.88.0.889144763106.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: Antoine, what if we add another function, rmtree_safe() that uses chdir() and document that it is protected from the race condition but may have the side effect of changing the current dir in threaded environment? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 12:26:42 2008 From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=) Date: Mon, 29 Dec 2008 11:26:42 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230550002.23.0.397566895825.issue4489@psf.upfronthosting.co.za> Mart S?mermaa added the comment: Replying to previous comment: > There's no way to do the "check inode then remove" sequence atomically. Right, although the attack window would be tiny, this is not a real solution. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 12:32:53 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 29 Dec 2008 11:32:53 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1230549561.88.0.889144763106.issue4489@psf.upfronthosting.co.za> Message-ID: <1230550374.10188.5.camel@localhost> Antoine Pitrou added the comment: > Antoine, what if we add another function, rmtree_safe() that uses > chdir() and document that it is protected from the race condition but > may have the side effect of changing the current dir in threaded > environment? I don't have any strong opinion on it, maybe it should be brought on the mailing-list (or just wait for some other devs to show up here). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 13:01:54 2008 From: report at bugs.python.org (anatoly techtonik) Date: Mon, 29 Dec 2008 12:01:54 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230552114.21.0.378775093232.issue4750@psf.upfronthosting.co.za> anatoly techtonik added the comment: For MSYS gzip added a bugreport here: https://sourceforge.net/tracker2/index.php?func=detail&aid=2474481&group_id=2435&atid=102435 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 13:22:27 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 29 Dec 2008 12:22:27 +0000 Subject: [issue4732] Object allocation stress leads to segfault on RHEL In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> Message-ID: <1230553347.16.0.858629585252.issue4732@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think you should report the bug to Redhat and see what they have to say about it. It may be a bug in the libc of that particular version. In any case I think it is highly inlikely to be a bug in Python itself. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 13:27:28 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 29 Dec 2008 12:27:28 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1230553648.27.0.873042934453.issue4489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, I've opened a separate bug entry for the creation of the openat(), etc. wrappers: #4761. Those functions seem to exist on recent Linux distros (even Debian stable). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 13:47:39 2008 From: report at bugs.python.org (ebfe) Date: Mon, 29 Dec 2008 12:47:39 +0000 Subject: [issue4746] Misguiding wording 3.0 c-api reference In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za> Message-ID: <1230554859.14.0.140483399752.issue4746@psf.upfronthosting.co.za> ebfe added the comment: Whenever the documentation says "you must not" it really says "don't do that or your application *will* crash, burn and die"... Of course I can allocate storage for the string, copy it's content and then free or - nothing will happen. How would it cause a crash - it's my own pointer. That's exactly the line between "not required to", "should not" and "must not": The current wording suggests that I may not even touch e.g. malloc which is confusing and in fact to be ignored in it's current state. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 14:26:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 29 Dec 2008 13:26:35 +0000 Subject: [issue4746] Misguiding wording 3.0 c-api reference In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za> Message-ID: <1230557195.8.0.172934389765.issue4746@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For me, when I read "You must not provide storage for the string itself", it obviously means I mustn't do so *before calling the PyArg_ParseTuple function*. It is also obvious that I am allowed to copy the returned contents wherever I want, and it should be obvious to any C programmer. So I don't see how the wording is misleading. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 14:31:41 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 13:31:41 +0000 Subject: [issue4746] Misguiding wording 3.0 c-api reference In-Reply-To: <1230554859.14.0.140483399752.issue4746@psf.upfronthosting.co.za> Message-ID: <4958D13A.1090904@v.loewis.de> Martin v. L?wis added the comment: > Whenever the documentation says "you must not" it really says "don't do > that or your application *will* crash, burn and die"... Of course I can > allocate storage for the string, copy it's content and then free or - > nothing will happen. How would it cause a crash - it's my own pointer. Suppose you do char *s = malloc(MAXPATH); if (!PyArg_ParseTuple("s", &s))return NULL; do_something_with(s); free(s); then your application *will* crash, burn, and die - because s gets changed in the call; the original malloc result is garbage, and the free call will likely crash the malloc implementation (as the block it points to wasn't malloc-allocated, and isn't the beginning of a block). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 14:37:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 29 Dec 2008 13:37:20 +0000 Subject: [issue4746] Misguiding wording 3.0 c-api reference In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za> Message-ID: <1230557840.0.0.464005135695.issue4746@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't see a reason to keep this open any longer. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 16:21:49 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 15:21:49 +0000 Subject: [issue4766] email documentation needs to be precise about strings/bytes In-Reply-To: <1230564109.29.0.851125901537.issue4766@psf.upfronthosting.co.za> Message-ID: <1230564109.29.0.851125901537.issue4766@psf.upfronthosting.co.za> New submission from David M. Beazley : Documentation for the email package needs to be more clear about the usage of strings and bytes. In particular: 1. All operations that parse email messages such as message_from_file() or message_from_string() operate on *text*, not binary data. So, the file must be opened in text mode. Strings must be text strings, not binary strings. 2. All operations that set/get the payload of a message operate on byte strings. For example, using m.get_payload() on a Message object returns binary data as a byte string. Opinion: There might be other bug reports about this, but I'm not advocating that the email module should support reading messages from binary mode files or byte strings. Email and MIME were originally developed with the assumption that messages would always be handled as text. Minimally, this assumed that messages would stay intact even if processed as 7-bit ASCII. By extension, everything should still work if processed as Unicode. So, I think the use of text-mode files is entirely consistent with this if you wanted to keep the module "as is." There may be some confusion on this matter because if you're reading or writing email messages (or sending them across a socket), you may encounter messages stored in the form of bytes strings instead of text. People will then wonder why a byte string can't be parsed by this module (especially given that email messages only use character values in the range of 0-127). ---------- assignee: georg.brandl components: Documentation messages: 78456 nosy: beazley, georg.brandl severity: normal status: open title: email documentation needs to be precise about strings/bytes type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 16:34:34 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 29 Dec 2008 15:34:34 +0000 Subject: [issue4766] email documentation needs to be precise about strings/bytes In-Reply-To: <1230564109.29.0.851125901537.issue4766@psf.upfronthosting.co.za> Message-ID: <1230564874.71.0.966662744757.issue4766@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: georg.brandl -> barry nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 16:43:07 2008 From: report at bugs.python.org (Allan Crooks) Date: Mon, 29 Dec 2008 15:43:07 +0000 Subject: [issue4643] cgitb.html fails if getattr call raises exception In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> Message-ID: <1230565387.16.0.232440134555.issue4643@psf.upfronthosting.co.za> Allan Crooks added the comment: In the interests of getting this fixed (and not letting it die), should I submit a proper patch? I suppose I would have to do one for each version of Python that is affected (which is all of them, really). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 16:55:08 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 15:55:08 +0000 Subject: [issue4767] email.mime incorrectly documented (or implemented) In-Reply-To: <1230566108.89.0.124705904062.issue4767@psf.upfronthosting.co.za> Message-ID: <1230566108.89.0.124705904062.issue4767@psf.upfronthosting.co.za> New submission from David M. Beazley : The documentation describes classes such as email.mime.MIMEText() email.mime.MIMEMultipart() email.mime.MIMEApplication() etc... However, it's confusing because none of these classes are actually found in email.mime. Suggest either using the full proper name: email.mime.text.MIMEText() Or just using the short name along with a note saying where it's found: MIMEText() Defined in email.mime.text. Further description, blah, blah.. Note: These classes *are* defined in email.mime in Python 2.6. ---------- assignee: georg.brandl components: Documentation messages: 78458 nosy: beazley, georg.brandl severity: normal status: open title: email.mime incorrectly documented (or implemented) type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 17:02:35 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 16:02:35 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1230566555.04.0.545394861712.issue3248@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Notice that the example function doesn't actually work; it gives _tkinter.TclError: wrong # args: should be ".148002724.148002500 insert index chars ?tagList chars tagList ...?" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 17:09:44 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 16:09:44 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1230566984.91.0.637004600452.issue3248@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks again for the patch. Merged into recent branches as r68006, r68007, r68008, and r68009 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 17:13:01 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 16:13:01 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1230567181.04.0.516606474822.issue3248@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> accepted status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 17:15:03 2008 From: report at bugs.python.org (Guilherme Polo) Date: Mon, 29 Dec 2008 16:15:03 +0000 Subject: [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1230566555.04.0.545394861712.issue3248@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Mon, Dec 29, 2008 at 2:02 PM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > Notice that the example function doesn't actually work; it gives > > _tkinter.TclError: wrong # args: should be ".148002724.148002500 insert > index chars ?tagList chars tagList ...?" The example function included didn't work for you ? I guess I misunderstood your message otherwise you wouldn't have commited it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 17:28:46 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 16:28:46 +0000 Subject: [issue3767] tkColorChooser may fail if no color is selected In-Reply-To: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za> Message-ID: <1230568126.77.0.964490326801.issue3767@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Committed into various branches as r68010, r68011, r68012, and r68013 ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 17:48:15 2008 From: report at bugs.python.org (Alan Brooks) Date: Mon, 29 Dec 2008 16:48:15 +0000 Subject: [issue3432] Mac, 2.6 framework install error In-Reply-To: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za> Message-ID: <1230569295.74.0.331214347616.issue3432@psf.upfronthosting.co.za> Alan Brooks added the comment: I also get this exact same problem. Mac OS 10.5.6 on an Intel MacBook trying to install the release version of 2.6.1. I found it was failing to build _Res, but worked around by *not* using --enable-universalsdk. ---------- nosy: +lanny _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:21:41 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 17:21:41 +0000 Subject: [issue4768] email.generator.Generator object bytes/str crash - b64encode() bug? In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za> Message-ID: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za> New submission from David M. Beazley : The email.generator.Generator class does not work correctly message objects created with binary data (MIMEImage, MIMEAudio, MIMEApplication, etc.). For example: >>> from email.mime.image import MIMEImage >>> data = open("IMG.jpg","rb").read() >>> m = MIMEImage(data,'jpeg') >>> s = m.as_string() Traceback (most recent call last): File "", line 1, in File "/tmp/lib/python3.0/email/message.py", line 136, in as_string g.flatten(self, unixfrom=unixfrom) File "/tmp/lib/python3.0/email/generator.py", line 76, in flatten self._write(msg) File "/tmp/lib/python3.0/email/generator.py", line 101, in _write self._dispatch(msg) File "/tmp/lib/python3.0/email/generator.py", line 127, in _dispatch meth(msg) File "/tmp/lib/python3.0/email/generator.py", line 155, in _handle_text raise TypeError('string payload expected: %s' % type(payload)) TypeError: string payload expected: >>> The source of the problem is rather complicated, but here is the gist of it. 1. Classes such as MIMEAudio and MIMEImage accept raw binary data as input. This data is going to be in the form of bytes. 2. These classes immediately encode the data using a base64 encoder. This encoder uses the library function base64.b64encode(). 3. base64.b64encode() takes a byte string as input and returns a byte string as output. So, even after encoding, the payload of the message is of type 'bytes' 4. When messages are generated, the method Generator._dispatch() is used. It looks at the MIME main type and subtype and tries to dispatch message processing to a handler method of the form '_handle_type_subtype'. If it can't find such a handler, it defaults to a method _writeBody(). For image and audio types, this is what happens. 5. _writeBody() is an alias for _handle_text(). 6. _handle_text() crashes because it's not expecting a payload of type 'bytes'. Suggested fix: I think the library function base64.b64encode() should return a string, not bytes. The whole point of base64 encoding is to take binary data and encode it into characters safe for inclusion in text strings. Other fixes: Modify the Generator class in email.generator to properly detect bytes and use a different _handle function for it. For instance, maybe add a _handle_binary() method. ---------- components: Library (Lib) messages: 78464 nosy: beazley severity: normal status: open title: email.generator.Generator object bytes/str crash - b64encode() bug? type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:26:45 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 29 Dec 2008 17:26:45 +0000 Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za> Message-ID: <1230571605.37.0.454212531162.issue4580@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nick, sorry for waving at you again, but do you have time for a review? Otherwise, is it ok if I commit the patch as is? (it solves the problems and there's no API or feature change anyway) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:28:30 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 17:28:30 +0000 Subject: [issue4768] email.generator.Generator object bytes/str crash - b64encode() bug? In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za> Message-ID: <1230571710.21.0.649331356787.issue4768@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> barry nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:35:53 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 17:35:53 +0000 Subject: [issue4769] b64decode should accept strings or bytes In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za> Message-ID: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za> New submission from David M. Beazley : The whole point of base64 encoding is to safely encode binary data into text characters. Thus, the base64.b64decode() function should equally accept text strings or binary strings as input. For example, there is a reasonable expectation that something like this should work: >>> x = 'SGVsbG8=' >>> base64.b64decode(x) b'Hello' >>> In Python 3, you get this exception however: >>> base64.b64decode(x) Traceback (most recent call last): File "", line 1, in File "/tmp/lib/python3.0/base64.py", line 80, in b64decode raise TypeError("expected bytes, not %s" % s.__class__.__name__) TypeError: expected bytes, not str >>> I realize that there are encoding issues with Unicode strings, but base64 encodes everything into the first 127 ASCII characters. If the input to b64decode is a str, just do a encode('ascii') operation on it and proceed. If that fails, it wasn't valid Base64 to begin with. I can't think of any real negative impact to making this change as long as the result is still always bytes. The main benefit is just simplifying the decoding process for end-users. See issue 4768. ---------- components: Library (Lib) messages: 78466 nosy: beazley severity: normal status: open title: b64decode should accept strings or bytes type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:39:33 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 17:39:33 +0000 Subject: [issue1034053] unittest.py patch: add skipped test functionality Message-ID: <1230572373.95.0.924444197531.issue1034053@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think this is a good improvement, and I hope it can make it into 2.7/3.1. Several comments on patch: - I don't like the name "SkipException" SkipTest is better IMO. - TestResult.addSkipped should be changed to TestResult.addSkip. - I'm not sure why TestResult.addSkipped gets sys.exc_info() pass in. I think you should just catch the exception and pass the reason ("str(e)") to addSkipped. - The patch needs docs before it can be applied. - As Antoine said, it would be nice to have decorators for skipping. When I implemented this, I added the skip() (unconditional skip) skip_if(condition, reason) and skip_unless(condition, reason) decorators. It should also be easy to extend the mechanism, so that custom decorators can be written. - It would nice to be able to skip whole classes, too. This could easily be done with class decorators. (Georg, I hope you don't mind if I "steal" this from you.) ---------- assignee: georg.brandl -> benjamin.peterson nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:39:55 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 17:39:55 +0000 Subject: [issue4769] b64decode should accept strings or bytes In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za> Message-ID: <1230572395.81.0.474545558755.issue4769@psf.upfronthosting.co.za> David M. Beazley added the comment: Note: This problem applies to all of the other decoders/encoders in the base64 too (b16, b32, etc.) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:57:19 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 17:57:19 +0000 Subject: [issue4764] open('existing_dir') -> IOError instance's attr filename is None In-Reply-To: <1230512634.5.0.564476088999.issue4764@psf.upfronthosting.co.za> Message-ID: <1230573439.42.0.304943059304.issue4764@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r68014 and r68016. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:00:53 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 18:00:53 +0000 Subject: [issue4770] binascii module, crazy error messages, unexpected behavior In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za> Message-ID: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za> New submission from David M. Beazley : See Issue 4869 for a related bug. Most of the functions in binascii are meant to go from binary data to textual representations (hex digits, base64, binhex, etc.). There are numerous problems: 1. Misleading error messages. For example: >>> binascii.b2a_base64("Some text") Traceback (most recent call last): File "", line 1, in TypeError: b2a_base64() argument 1 must be string or buffer, not str >>> binascii.crc32("Some text") Traceback (most recent call last): File "", line 1, in TypeError: crc32() argument 1 must be string or buffer, not str >>> Huh? Didn't I just pass a string? Error message should say "argument 1 must be bytes or buffer, not str". This problem shows up with most of the other encoding functions too (i.e., b2a_uu). 2. Expected behavior with encoding/decoding. The functions in this module are going from binary to text. To be consistent, I think the result of encoding operations such as b2a_uu(), b2a_base64(), should be strings, not bytes. Similarly, decoding operations are going from text back to bytes. I think the input arguments should be allowed to be str (in addition to bytes if you want). ---------- components: Library (Lib) messages: 78470 nosy: beazley severity: normal status: open title: binascii module, crazy error messages, unexpected behavior type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:15:41 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 29 Dec 2008 18:15:41 +0000 Subject: [issue4400] pypirc default is not at the right format In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za> Message-ID: <1230574541.74.0.0317327442731.issue4400@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The patch was applied in trunk, release26-maint and py3k. Can this issue be closed, or do you plan to merge it into release30-maint? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:26:51 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 18:26:51 +0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1230575211.25.0.66160235576.issue1040026@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Malte, thanks again for the patch; committed into the various branches as r68018, r68019, r68020, r68021. As annunciated, I reject the test; I don't think there is a reasonable way to test for this bug. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:36:36 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 29 Dec 2008 18:36:36 +0000 Subject: [issue4770] binascii module, crazy error messages, unexpected behavior In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za> Message-ID: <1230575796.83.0.39950433314.issue4770@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Item 1 was most probably fixed recently with r67929. Concerning item 2, I think it was decided that binascii is a bytes-only module. I suggest to close this issue as "out of date". ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:47:21 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 18:47:21 +0000 Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on Windows) In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za> Message-ID: <1230576441.77.0.383553597578.issue4323@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the review. Committed (with the proposed change) as r68022 and r68023. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:54:18 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 18:54:18 +0000 Subject: [issue4770] binascii module, crazy error messages, unexpected behavior In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za> Message-ID: <1230576858.83.0.294247762842.issue4770@psf.upfronthosting.co.za> David M. Beazley added the comment: Given the low-level nature of this module, I can understand the motivation to make it all bytes. However, I'm going to respectfully disagree with that and claim that making binascii all bytes really goes against the whole spirit of what Python 3.0 has tried to do for Unicode. For example, throughout Python, you now have a clean separation between binary data (bytes) and text data (str). Well, it's cleanly separated everywhere except in the binascii module (and base64 module) which, ironically, is all about converting between binary data and text. As it stands now, it's a huge wart IMHO. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:59:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 18:59:20 +0000 Subject: [issue4049] IDLE does not open too In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za> Message-ID: <1230577160.3.0.540036525698.issue4049@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Since there was no feedback from the OP, I'm closing this as "works for me". ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 20:41:56 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 19:41:56 +0000 Subject: [issue4623] IDLE shutdown if I run an edited file contains chinese In-Reply-To: <1228961224.5.0.652279598263.issue4623@psf.upfronthosting.co.za> Message-ID: <1230579716.14.0.422463490729.issue4623@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a duplicate of issue 4008. ---------- nosy: +loewis resolution: -> duplicate status: open -> closed superseder: -> IDLE: checksyntax() doesn't support Unicode? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 20:42:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 19:42:25 +0000 Subject: [issue4410] IDLE string problem in Run/Run Module In-Reply-To: <1227550609.93.0.240511987484.issue4410@psf.upfronthosting.co.za> Message-ID: <1230579745.66.0.291221277931.issue4410@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a duplicate of issue 4008 ---------- nosy: +loewis resolution: -> duplicate status: open -> closed superseder: -> IDLE: checksyntax() doesn't support Unicode? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 20:48:28 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 19:48:28 +0000 Subject: [issue4008] IDLE: checksyntax() doesn't support Unicode? In-Reply-To: <1222875475.18.0.22602254781.issue4008@psf.upfronthosting.co.za> Message-ID: <1230580108.53.0.248511338316.issue4008@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Here is a new patch that fixes this issue, and the duplicate issues (#4410, and #4623). It doesn't try to eliminate code duplication, but fixes coding_spec by decoding always to Latin-1 first until the coding is known. It fixes check_syntax by opening the source file in binary. It should have fixed tabnanny the same way, except that tabnanny cannot properly process byte tokens. ---------- keywords: +needs review priority: -> release blocker Added file: http://bugs.python.org/file12486/idle_encoding_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 20:54:13 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 19:54:13 +0000 Subject: [issue4771] Bad examples in hashlib documentation In-Reply-To: <1230580453.49.0.84124540876.issue4771@psf.upfronthosting.co.za> Message-ID: <1230580453.49.0.84124540876.issue4771@psf.upfronthosting.co.za> New submission from David M. Beazley : The hashlib documentation has incorrect examples showing the use of the hexdigest() method: >>> hashlib.sha224(b"Nobody inspects the spammish repetition").hexdigest() b'a4337bc45a8fc544c03f52dc550cd6e1e87021bc896588bd79e901e2' >>> and this one >>> h = hashlib.new('ripemd160') >>> h.update(b"Nobody inspects the spammish repetition") >>> h.hexdigest() b'cc4a5ce1b3df48aec5d22d1f16b894a0b894eccc' >>> However, the result of h.hexdigest() is of type 'str', not bytes. Actual output: >>> h.hexdigest() 'cc4a5ce1b3df48aec5d22d1f16b894a0b894eccc' >>> Sure would be nice if that string of hex digits was easy to decode back into a binary string. >>> import binascii >>> b = binascii.a2b_hex(h.hexdigest()) >>> Hmmm. So *SOME* of the functions in binascii do accept Unicode strings. See Issue 4470 :-). ---------- assignee: georg.brandl components: Documentation messages: 78480 nosy: beazley, georg.brandl severity: normal status: open title: Bad examples in hashlib documentation type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 21:27:08 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 20:27:08 +0000 Subject: [issue4771] Bad examples in hashlib documentation In-Reply-To: <1230580453.49.0.84124540876.issue4771@psf.upfronthosting.co.za> Message-ID: <1230582428.98.0.37196574493.issue4771@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Shouldn't hash algorithms give bytes results anyway? ---------- components: +Library (Lib) -Documentation nosy: +benjamin.peterson priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 21:33:33 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 20:33:33 +0000 Subject: [issue4771] Bad examples in hashlib documentation In-Reply-To: <1230580453.49.0.84124540876.issue4771@psf.upfronthosting.co.za> Message-ID: <1230582813.91.0.561368381173.issue4771@psf.upfronthosting.co.za> David M. Beazley added the comment: The digest() method of hashes does produce bytes (correct). The hexdigest() method produces a string, but it is also shown as producing bytes in the examples. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 21:36:13 2008 From: report at bugs.python.org (dontbugme) Date: Mon, 29 Dec 2008 20:36:13 +0000 Subject: [issue4772] undesired switch fall-through in socketmodule.c In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za> Message-ID: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za> New submission from dontbugme : makesockaddr() in socketmodule.c will fall through from AF_BLUETOOTH to AF_PACKET if none of Bluetooth protocols match. That's not a very appropriate thing to do. ---------- messages: 78483 nosy: dontbugme severity: normal status: open title: undesired switch fall-through in socketmodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 21:52:28 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 20:52:28 +0000 Subject: [issue4771] Bad examples in hashlib documentation In-Reply-To: <1230580453.49.0.84124540876.issue4771@psf.upfronthosting.co.za> Message-ID: <1230583948.81.0.445315123776.issue4771@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r68027. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 22:35:34 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 29 Dec 2008 21:35:34 +0000 Subject: [issue4400] pypirc default is not at the right format In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za> Message-ID: <1230586534.59.0.931569830187.issue4400@psf.upfronthosting.co.za> Tarek Ziad? added the comment: Yes, I was waiting to merge it to release30-maint then close it. I'll do it then close it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 22:42:32 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 21:42:32 +0000 Subject: [issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0 In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za> Message-ID: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za> New submission from David M. Beazley : A file-like object u returned by the urlopen() function in both Python 2.6/3.0 has a method info() that returns a 'HTTPMessage' object. For example: ::: Python 2.6 >>> from urllib2 import urlopen >>> u = urlopen("http://www.python.org") >>> u.info() >>> ::: Python 3.0 >>> from urllib.request import urlopen >>> u = urlopen("http://www.python.org") >>> u.info() >>> So far, so good. HTTPMessage is defined in two different modules, but that's fine (it's just library reorganization). Two major problems: 1. There is no documentation whatsoever on HTTPMessage. No description in the docs for httplib (python 2.6) or http.client (python 3.0). 2. The HTTPMessage object in Python 2.6 derives from mimetools.Message and has a totally different programming interface than HTTPMessage in Python 3.0 which derives from email.message.Message. Check it out: :::Python 2.6 >>> dir(u.info()) ['__contains__', '__delitem__', '__doc__', '__getitem__', '__init__', '__iter__', '__len__', '__module__', '__setitem__', '__str__', 'addcontinue', 'addheader', 'dict', 'encodingheader', 'fp', 'get', 'getaddr', 'getaddrlist', 'getallmatchingheaders', 'getdate', 'getdate_tz', 'getencoding', 'getfirstmatchingheader', 'getheader', 'getheaders', 'getmaintype', 'getparam', 'getparamnames', 'getplist', 'getrawheader', 'getsubtype', 'gettype', 'has_key', 'headers', 'iscomment', 'isheader', 'islast', 'items', 'keys', 'maintype', 'parseplist', 'parsetype', 'plist', 'plisttext', 'readheaders', 'rewindbody', 'seekable', 'setdefault', 'startofbody', 'startofheaders', 'status', 'subtype', 'type', 'typeheader', 'unixfrom', 'values'] :::Python 3.0 >>> dir(u.info()) ['__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_charset', '_default_type', '_get_params_preserve', '_headers', '_payload', '_unixfrom', 'add_header', 'as_string', 'attach', 'defects', 'del_param', 'epilogue', 'get', 'get_all', 'get_boundary', 'get_charset', 'get_charsets', 'get_content_charset', 'get_content_maintype', 'get_content_subtype', 'get_content_type', 'get_default_type', 'get_filename', 'get_param', 'get_params', 'get_payload', 'get_unixfrom', 'getallmatchingheaders', 'is_multipart', 'items', 'keys', 'preamble', 'replace_header', 'set_boundary', 'set_charset', 'set_default_type', 'set_param', 'set_payload', 'set_type', 'set_unixfrom', 'values', 'walk'] I know that getting rid of mimetools was desired, but I have no idea if changing the API on HTTPMessage was intended or not. In any case, it's one of the only cases in the entire library where the programming interface to an object radically changes from 2.6 -> 3.0. I ran into this problem with code that was trying to properly determine the charset encoding of the byte string returned by urlopen(). I haven't checked whether 2to3 deals with this or not, but it might be something for someone to look at in their copious amounts of spare time. ---------- components: Library (Lib) messages: 78486 nosy: beazley severity: normal status: open title: HTTPMessage not documented and has inconsistent API across 2.6/3.0 type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 22:44:49 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 29 Dec 2008 21:44:49 +0000 Subject: [issue4400] pypirc default is not at the right format In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za> Message-ID: <1230587089.12.0.891266818622.issue4400@psf.upfronthosting.co.za> Tarek Ziad? added the comment: I am not sure what is the best way to merge it from 3k branch to release30-maint since the original change was done with an automatic merge from trunk to 3k branch with several other changes, then a slight fix so the 2.x code works under 3.x. Should I do a manual merge in release30-maint or there's a special way to handle it ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 22:50:56 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 29 Dec 2008 21:50:56 +0000 Subject: [issue4673] Distutils should provide an uninstall command In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za> Message-ID: <1230587456.23.0.655181599539.issue4673@psf.upfronthosting.co.za> Tarek Ziad? added the comment: This would require a detailed description on how such a feature would work. ---------- nosy: +tarek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 22:51:27 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Dec 2008 21:51:27 +0000 Subject: [issue4400] pypirc default is not at the right format In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za> Message-ID: <1230587487.93.0.532839918817.issue4400@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Assigning to Benjamin, since he merged the change to 3k. For the record, the revisions are these: r67926, r67944, r67948 ---------- assignee: tarek -> benjamin.peterson nosy: +benjamin.peterson, loewis priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:04:51 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 22:04:51 +0000 Subject: [issue4400] pypirc default is not at the right format In-Reply-To: <1230587487.93.0.532839918817.issue4400@psf.upfronthosting.co.za> Message-ID: <1afaf6160812291404k6b77ef59ta6936b3c3605605a@mail.gmail.com> Benjamin Peterson added the comment: On Mon, Dec 29, 2008 at 3:51 PM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > Assigning to Benjamin, since he merged the change to 3k. > > For the record, the revisions are these: r67926, r67944, r67948 And now r68031. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:05:17 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 22:05:17 +0000 Subject: [issue4400] pypirc default is not at the right format In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za> Message-ID: <1230588317.99.0.751215513718.issue4400@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:06:54 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 29 Dec 2008 22:06:54 +0000 Subject: [issue4646] distutils chokes on empty options arg in the setup function In-Reply-To: <1229112904.14.0.0159399234206.issue4646@psf.upfronthosting.co.za> Message-ID: <1230588414.02.0.643538137697.issue4646@psf.upfronthosting.co.za> Changes by Tarek Ziad? : ---------- assignee: -> tarek nosy: +tarek priority: -> low resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:10:44 2008 From: report at bugs.python.org (Jeff Hall) Date: Mon, 29 Dec 2008 22:10:44 +0000 Subject: [issue4755] Common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1230588644.42.0.134469891987.issue4755@psf.upfronthosting.co.za> Changes by Jeff Hall : ---------- nosy: +laxrulz777 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:20:28 2008 From: report at bugs.python.org (David M. Beazley) Date: Mon, 29 Dec 2008 22:20:28 +0000 Subject: [issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0 In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za> Message-ID: <1230589228.23.0.320176844615.issue4773@psf.upfronthosting.co.za> David M. Beazley added the comment: Verified that 2to3 does not fix this. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:28:25 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 29 Dec 2008 22:28:25 +0000 Subject: [issue4646] distutils chokes on empty options arg in the setup function In-Reply-To: <1229112904.14.0.0159399234206.issue4646@psf.upfronthosting.co.za> Message-ID: <1230589705.34.0.0385472162619.issue4646@psf.upfronthosting.co.za> Tarek Ziad? added the comment: applied with a test in r68033, thanks for the patch ! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:45:53 2008 From: report at bugs.python.org (anatoly techtonik) Date: Mon, 29 Dec 2008 22:45:53 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230590753.38.0.999259657776.issue4750@psf.upfronthosting.co.za> anatoly techtonik added the comment: I attach patch for Python 2.6 gzip I clarified the meaning of self.name to be the basename corresponding to FNAME field in GZIP file header. There is a trace of deprecated gzip.filename API - I haven't found any references to it in documentation, so I removed it. In Python 2.5 it seemed to mean just filename in read mode and filename + .gz in write mode even if opened filename did not end with .gz If FNAME field from gzip header is ignored in read mode, so we want to make self.filename or self.name available via API - we need to agree what it should be - basename of archived file or path filename of archive itself. Added file: http://bugs.python.org/file12487/4750.gzip.basename.fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 00:20:53 2008 From: report at bugs.python.org (Alain Spineux) Date: Mon, 29 Dec 2008 23:20:53 +0000 Subject: [issue4774] threding, bsddb and double free or corruption (fasttop) In-Reply-To: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za> Message-ID: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za> New submission from Alain Spineux : This is a test script, to help me to understand why I have unexpected result in application. But I got a more unexpected result, and probably wrong error message about the read-only cursor. The full script is at the end. I got this only one ! I restart the script after the crash, but this has freezed my xen virtual machine after some minutes. I had to "destroy" it and restart it. After restart was not working anymore, blocked, not responding except to CTRL-C I had to drop the old DB, and then i worked again I run python 2.5.2 inside a kolab 2.2.0 (aka openpkg) environement on a xen centos 5.x running kernel 2.6.18-8.el5xen and glibc-2.5-12 The host is a P4 running centos 5.X and kernel 2.6.18-53.1.4.el5xen Here are the errors, I waited for long time after the firts backtrace, to press CTRL-C and got immediately the second backtrace. Regards db cleanup, 326 records deleted, 9990 remains Exception in thread Thread-1: Traceback (most recent call last): File "/kolab/lib/python/threading.py", line 486, in __bootstrap_inner self.run() File "/kolab/lib/python/threading.py", line 446, in run self.__target(*self.__args, **self.__kwargs) File "./test/test_bdb.py", line 85, in update_thread=threading.Thread(target=lambda : cleanup(db)) File "./test/test_bdb.py", line 72, in cleanup cursor.delete() DBPermissionsError: (1, 'Operation not permitted -- Write attempted on read- only cursor') Traceback (most recent call last): File "./test/test_bdb.py", line 130, in server() File "./test/test_bdb.py", line 92, in server db[str(last)]=str(last) KeyboardInterrupt *** glibc detected *** /kolab/bin/python: double free or corruption (fasttop): 0 x09d521a8 *** ======= Backtrace: ========= /lib/i686/nosegneg/libc.so.6[0x4444ccfd] /lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x444503b0] /kolab/bin/python(__db_c_destroy+0x60)[0x81fa6f0] /kolab/bin/python(__db_refresh+0x165)[0x81f3515] /kolab/bin/python(__db_close+0x64)[0x81f3cb4] /kolab/bin/python(__db_close_pp+0xa1)[0x8204b61] /kolab/bin/python[0x812123f] /kolab/bin/python[0x8159534] /kolab/bin/python[0x815fb0a] /kolab/bin/python[0x811abbc] /kolab/bin/python[0x811abc9] /kolab/bin/python[0x80b0229] /kolab/bin/python(PyDict_SetItem+0x6e)[0x80b1c0e] /kolab/bin/python(PyDict_SetItemString+0x42)[0x80b1ce2] /kolab/bin/python(PyImport_Cleanup+0xd4)[0x8108294] /kolab/bin/python(Py_Finalize+0xbf)[0x8113f1f] /kolab/bin/python(Py_Main+0x468)[0x80845c8] /kolab/bin/python(main+0x22)[0x8084052] /lib/i686/nosegneg/libc.so.6(__libc_start_main+0xdc)[0x443fbdec] /kolab/bin/python[0x8083fa1] ======= Memory map: ======== 00110000-001d7000 rwxp 00110000 00:00 0 001d7000-001da000 r-xp 00000000 ca:03 973941 /kolab/lib/python/lib- dynload/ t ime.so 001da000-001dc000 rwxp 00002000 ca:03 973941 /kolab/lib/python/lib- dynload/ t ime.so 001dc000-001e0000 r-xp 00000000 ca:03 973938 /kolab/lib/python/lib- dynload/ s trop.so 001e0000-001e2000 rwxp 00003000 ca:03 973938 /kolab/lib/python/lib- dynload/ s trop.so 001e2000-001e3000 r-xp 00000000 ca:03 973911 /kolab/lib/python/lib- dynload/ _ weakref.so 001e3000-001e4000 rwxp 00000000 ca:03 973911 /kolab/lib/python/lib- dynload/ _ weakref.so 001e4000-001ea000 rwxs 00000000 ca:03 1747650 /tmp/db/__db.001 001ea000-001fc000 rwxs 00000000 ca:03 1747651 /tmp/db/__db.002 001fc000-0023e000 rwxs 00000000 ca:03 1747652 /tmp/db/__db.003 00388000-003e0000 rwxs 00000000 ca:03 1747653 /tmp/db/__db.004 00450000-00452000 r-xp 00000000 ca:03 1132355 /lib/libutil-2.5.so 00452000-00453000 r-xp 00001000 ca:03 1132355 /lib/libutil-2.5.so 00453000-00454000 rwxp 00002000 ca:03 1132355 /lib/libutil-2.5.so 00459000-0047e000 r-xp 00000000 ca:03 1132349 /lib/i686/nosegneg/ libm-2.5.so 0047e000-0047f000 r-xp 00024000 ca:03 1132349 /lib/i686/nosegneg/ libm-2.5.so 0047f000-00480000 rwxp 00025000 ca:03 1132349 /lib/i686/nosegneg/ libm-2.5.so 0063e000-0063f000 r-xp 0063e000 00:00 0 [vdso] 0097a000-0098d000 r-xp 00000000 ca:03 1134447 /lib/i686/nosegneg/ libpthread-2 . 5.so 0098d000-0098e000 r-xp 00012000 ca:03 1134447 /lib/i686/nosegneg/ libpthread-2 . 5.so 0098e000-0098f000 rwxp 00013000 ca:03 1134447 /lib/i686/nosegneg/ libpthread-2 . 5.so 0098f000-00991000 rwxp 0098f000 00:00 0 009a8000-009e9000 rwxp 009a8000 00:00 0 00b80000-00d80000 r-xp 00000000 ca:03 845325 /usr/lib/locale/ locale-archive 00ec9000-00ecc000 r-xp 00000000 ca:03 973916 /kolab/lib/python/lib- dynload/ c StringIO.so 00ecc000-00ecd000 rwxp 00003000 ca:03 973916 /kolab/lib/python/lib- dynload/ c StringIO.so 00fd2000-00fd6000 r-xp 00000000 ca:03 973918 /kolab/lib/python/lib- dynload/ c ollections.so 00fd6000-00fd7000 rwxp 00004000 ca:03 973918 /kolab/lib/python/lib- dynload/ c ollections.so 00fd7000-00fd8000 --xp 00fd7000 00:00 0 00fd8000-019d8000 rwxp 00fd8000 00:00 0 08048000-08433000 r-xp 00000000 ca:03 430731 /kolab/bin/python 08433000-0846e000 rwxp 003eb000 ca:03 430731 /kolab/bin/python 0846e000-08478000 rwxp 0846e000 00:00 0 09ce5000-09da5000 rwxp 09ce5000 00:00 0 443c4000-443dd000 r-xp 00000000 ca:03 1132323 /lib/ld-2.5.so 443dd000-443de000 r-xp 00018000 ca:03 1132323 /lib/ld-2.5.so 443de000-443df000 rwxp 00019000 ca:03 1132323 /lib/ld-2.5.so 443e6000-44521000 r-xp 00000000 ca:03 1134399 /lib/i686/nosegneg/ libc-2.5.so 44521000-44523000 r-xp 0013a000 ca:03 1134399 /lib/i686/nosegneg/ libc-2.5.so 44523000-44524000 rwxp 0013c000 ca:03 1134399 /lib/i686/nosegneg/ libc-2.5.so 44524000-44527000 rwxp 44524000 00:00 0 44529000-4452b000 r-xp 00000000 ca:03 1134402 /lib/libdl-2.5.so 4452b000-4452c000 r-xp 00001000 ca:03 1134402 /lib/libdl-2.5.so 4452c000-4452d000 rwxp 00002000 ca:03 1134402 /lib/libdl-2.5.so 44622000-4462d000 r-xp 00000000 ca:03 1134413 /lib/ libgcc_s-4.1.1-20070105.so . 1Aborted #!/kolab/bin/python import os, sys, logging, time, threading import marshal import bsddb.db # this is a test to see how bsddb is reliable # The server count in the db, and the client search for missing value # run on server in a terminal, and a client in another # ====================================================================== # db functions # ====================================================================== db_dir='/tmp/db' db_filename=os.path.join(db_dir, 'test.bdb') try: os.mkdir(db_dir) except OSError: pass freq=100 # new sample per/sec timeout=3 # in sec, how long I wait for them retention=100 # in sec, how long they stay in the db def init_db(read_only=True): # open the environement dbenv=db=None try: db_env=bsddb.db.DBEnv(0) flags=bsddb.db.DB_CREATE | bsddb.db.DB_INIT_CDB | bsddb.db.DB_INIT_MPOOL db_env.open(db_dir, flags) db=bsddb.db.DB(db_env) flags = bsddb.db.DB_DIRTY_READ | ( bsddb.db.DB_RDONLY if read_only else bsddb.db.DB_CREATE ) db.open(db_filename, dbtype=bsddb.db.DB_HASH,flags=flags) except Exception: print 'error opening db' raise else: print 'db opened' return dbenv, db # ---------------------------------------------------------------------- def close_db(dbenv, db): try: if db: db.close() if dbenv: db_env.close() except Exception: log.rcpt.exception('closing db') else: log.rcpt.info('db closed') # ---------------------------------------------------------------------- def now(): return int(time.time()*freq) def cleanup(db): while True: cursor=db.cursor(None, bsddb.db.DB_WRITECURSOR) count=remain=0 c=cursor.first() limit=now()-retention*freq while c: k, v=c t=int(k) if t<=limit: cursor.delete() count+=1 else: remain+=1 c=cursor.next() cursor.close() print 'db cleanup, %d records deleted, %d remains' % (count, remain) time.sleep(timeout) def server(): dbenv, db=init_db(read_only=False) update_thread=threading.Thread(target=lambda : cleanup(db)) update_thread.setDaemon(True) update_thread.start() last=now() while True: while lastmax_delay: max_delay=delay print 'delay', max_delay last+=1 close_db(dbenv, db) if sys.argv[1]=='c': client() elif sys.argv[1]=='s': server() ---------- components: Interpreter Core messages: 78494 nosy: aspineux severity: normal status: open title: threding, bsddb and double free or corruption (fasttop) type: crash versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 00:24:46 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2008 23:24:46 +0000 Subject: [issue4774] threding, bsddb and double free or corruption (fasttop) In-Reply-To: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za> Message-ID: <1230593086.48.0.268631196807.issue4774@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> jcea nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 00:29:27 2008 From: report at bugs.python.org (dedded) Date: Mon, 29 Dec 2008 23:29:27 +0000 Subject: [issue3023] Problem with invalidly-encoded command-line arguments (Unix) In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za> Message-ID: <1230593367.61.0.990144970258.issue3023@psf.upfronthosting.co.za> Changes by dedded : ---------- nosy: +dedded _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 01:36:48 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Tue, 30 Dec 2008 00:36:48 +0000 Subject: [issue4774] threding, bsddb and double free or corruption (fasttop) In-Reply-To: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za> Message-ID: <1230597408.42.0.945754074512.issue4774@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Alain, you are seeing a resource exhaustion problem. Somewhere memory is leaking. That is, the programs are leaking memory. bsddb was vastly improved in python 2.6. In particular, memory leaks and resource tree deallocations. Can you consider use that version?. You can install and updated pybsddb version in python 2.5. See http://www.jcea.es/programacion/pybsddb.htm. Just remember that the module is called "bsddb3" instead of "bsddb". You can easily install it using setuptools ("easy_install" script). Please, confirm that the problem vanished with the new module. What Berkeley DB are you using with bsddb bindings?. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 02:39:51 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 30 Dec 2008 01:39:51 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1230601191.21.0.867380517051.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed using a lazy call to PyType_Ready in PyObject_Hash: 2.7: r68051 2.6: r68052 Forward-port to Py3k still to come. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 03:17:22 2008 From: report at bugs.python.org (David Morley) Date: Tue, 30 Dec 2008 02:17:22 +0000 Subject: [issue4775] Incorrect documentation - UTC time In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za> Message-ID: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za> New submission from David Morley : There is a systemic error in the Python documentation on time (such as ). The term UTC is used incorrectly in the documentation where the term UT1 should be used. The difference is that UTC includes leap seconds, whereas UT1 does not (see ). The conversion routines ignore leap seconds, e.g., (time.mktime((2000,1,1,12,0,0,0,0,0))- time.mktime((1990,1,1,12,0,0,0,0,0))) returns an exact multiple of 24*60*60 and does not include all the leap seconds added between those dates. Using UT1 is more sensible that using UTC, since with UTC it is impossible to know when future leap seconds will be added, and hence impossible to convert future times to a number of seconds past the epoch. ---------- assignee: georg.brandl components: Documentation messages: 78497 nosy: georg.brandl, luckmor severity: normal status: open title: Incorrect documentation - UTC time versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 03:29:23 2008 From: report at bugs.python.org (Kevin Walzer) Date: Tue, 30 Dec 2008 02:29:23 +0000 Subject: [issue3883] Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text. In-Reply-To: <1221598645.05.0.789748104063.issue3883@psf.upfronthosting.co.za> Message-ID: <1230604163.68.0.0809679386208.issue3883@psf.upfronthosting.co.za> Kevin Walzer added the comment: The attached patch to configDialog.py fixes this problem--all that was needed was to remove the internal padding in the buttons. ---------- keywords: +patch nosy: +wordtech type: -> behavior Added file: http://bugs.python.org/file12488/configDialog.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 03:34:36 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 30 Dec 2008 02:34:36 +0000 Subject: [issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine In-Reply-To: <1221293791.14.0.791013716362.issue3833@psf.upfronthosting.co.za> Message-ID: <1230604476.2.0.443401340984.issue3833@psf.upfronthosting.co.za> Changes by Guilherme Polo : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 03:37:56 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 30 Dec 2008 02:37:56 +0000 Subject: [issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine In-Reply-To: <1221293791.14.0.791013716362.issue3833@psf.upfronthosting.co.za> Message-ID: <1230604676.5.0.190824681907.issue3833@psf.upfronthosting.co.za> Guilherme Polo added the comment: Jimmy Retzlaff (msg73003): I'm seeing the same symptoms that are described in issue 1543 with the 2.6b3 MSIs. Namely, when you run one of the MSIs (either 32-bit or 64-bit) then the other will refuse to install. This is on XP Pro x64 SP2. python-3.0b3.msi and python-3.0b3.amd64.msi exhibit the same problem. Having 32-bit and 64-bit version coexist makes it much easier to build extensions for and test on both versions at the same time. -- Sorry, was going through some issue and unlinked the initial message by mistake. ---------- nosy: +gpolo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 03:42:04 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 30 Dec 2008 02:42:04 +0000 Subject: [issue4760] cmp gone---What's new in 3.1 In-Reply-To: <1230436607.02.0.835606741355.issue4760@psf.upfronthosting.co.za> Message-ID: <1230604924.21.0.037352949858.issue4760@psf.upfronthosting.co.za> Guilherme Polo added the comment: Uhm ? The builtin cmp wasn't removed. ---------- nosy: +gpolo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 03:52:09 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 30 Dec 2008 02:52:09 +0000 Subject: [issue4096] Lib/lib2to3/*.pickle are shipped / modified in the build In-Reply-To: <1223623372.4.0.845692129772.issue4096@psf.upfronthosting.co.za> Message-ID: <1230605529.46.0.291792467661.issue4096@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Shall we close this as "works for me"? The files aren't included in Subversion and are built when 2to3 is used, so I don't see the problem. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 05:19:39 2008 From: report at bugs.python.org (steve21) Date: Tue, 30 Dec 2008 04:19:39 +0000 Subject: [issue4776] distutils documentation In-Reply-To: <1230610779.11.0.0228162085624.issue4776@psf.upfronthosting.co.za> Message-ID: <1230610779.11.0.0228162085624.issue4776@psf.upfronthosting.co.za> New submission from steve21 : 'data_files' and 'package_dir' are arguments for distutils.core.setup that some packages use in their setup.py. However, the manual entry for distutils.core. setup, at http://docs.python.org/dev/3.0/distutils/apiref.html#module-distutils.core does not document these arguments. ---------- assignee: georg.brandl components: Documentation messages: 78502 nosy: georg.brandl, steve21 severity: normal status: open title: distutils documentation versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 05:21:46 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Tue, 30 Dec 2008 04:21:46 +0000 Subject: [issue4643] cgitb.html fails if getattr call raises exception In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za> Message-ID: <1230610906.43.0.661398183588.issue4643@psf.upfronthosting.co.za> Gabriel Genellina added the comment: I believe a patch against the trunk would be enough, but should include a test case. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 05:51:26 2008 From: report at bugs.python.org (Chris Morrow) Date: Tue, 30 Dec 2008 04:51:26 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230612686.19.0.676104879468.issue1664@psf.upfronthosting.co.za> Chris Morrow added the comment: This patch doesn't appear to work for python2.5.1 -> Python 2.5.1 (r251:54863, Jun 15 2008, 18:24:51) [GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from nntplib import NNTP >>> conn = NNTP('newszilla6.xs4all.nl') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/nntplib.py", line 114, in __init__ self.sock = socket.create_connection((host, port)) AttributeError: 'module' object has no attribute 'create_connection' (at least for me it doesn't work... Linux hostnamehere 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 2008 i686 i686 i386 GNU/Linux) I'd be happy to try something else, or debug in other ways it that'd help... This really ought to get fixed if possible. ---------- nosy: +morrowc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 06:01:58 2008 From: report at bugs.python.org (Derek Morr) Date: Tue, 30 Dec 2008 05:01:58 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230613318.27.0.332005704491.issue1664@psf.upfronthosting.co.za> Derek Morr added the comment: Yes. The patch is against 2.6. It uses the socket.create_connection() helper function, which was added in 2.6. See http://svn.python.org/view? rev=54546&view=rev for the commit message. If you really want to apply it to 2.5, it's trivial to adapt the patch. Just replace the call to create_connection() with something like this: msg = "getaddrinfo returns an empty list" for res in getaddrinfo(host, port, 0, SOCK_STREAM): af, socktype, proto, canonname, sa = res sock = None try: sock = socket(af, socktype, proto) if timeout is not _GLOBAL_DEFAULT_TIMEOUT: sock.settimeout(timeout) sock.connect(sa) self.sock = sock except error, msg: if sock is not None: sock.close() raise error, msg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 06:05:17 2008 From: report at bugs.python.org (Chris Morrow) Date: Tue, 30 Dec 2008 05:05:17 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230613517.1.0.18211223484.issue1664@psf.upfronthosting.co.za> Chris Morrow added the comment: oh crap :( I saw the 2.6 AFTER I posted the message :( sorry. grr, have to find a fix for 2.5 I suppose now. Thanks. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 06:06:35 2008 From: report at bugs.python.org (Chris Morrow) Date: Tue, 30 Dec 2008 05:06:35 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230613595.79.0.722502106156.issue1664@psf.upfronthosting.co.za> Chris Morrow added the comment: oy, and I'm not reading emails properly. I'll try the fix you propose for 2.5. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 07:08:50 2008 From: report at bugs.python.org (Chris Morrow) Date: Tue, 30 Dec 2008 06:08:50 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230617330.65.0.87253559937.issue1664@psf.upfronthosting.co.za> Chris Morrow added the comment: a possible fix for 2.5 is: morrowc at tweezer:/tmp$ diff -U3 nntplib.py.orig nntplib.py --- nntplib.py.orig 2008-12-30 01:06:14.000000000 -0500 +++ nntplib.py 2008-12-30 01:07:33.000000000 -0500 @@ -109,8 +109,19 @@ """ self.host = host self.port = port - self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) - self.sock.connect((self.host, self.port)) + msg = "getaddrinfo returns an empty list" + for res in socket.getaddrinfo(self.host, self.port, 0, socket.SOCK_STREAM): + af, socktype, proto, canonname, sa = res + sock = None + try: + self.sock = socket.socket(af, socktype, proto) + self.sock.connect(sa) + + except error, msg: + if self.sock is not None: + self.sock.close() + raise NNTPError, msg + self.file = self.sock.makefile('rb') self.debugging = 0 self.welcome = self.getresp() I'll open a bug against 2.5 now with this. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 07:12:16 2008 From: report at bugs.python.org (Chris Morrow) Date: Tue, 30 Dec 2008 06:12:16 +0000 Subject: [issue4777] nntplib - python 2.5 In-Reply-To: <1230617536.56.0.797389880383.issue4777@psf.upfronthosting.co.za> Message-ID: <1230617536.56.0.797389880383.issue4777@psf.upfronthosting.co.za> New submission from Chris Morrow : nntplib.py on python2.5 is not IPv6 ready. The below patch at least makes connections on both ipv4 and ipv6 to servers. This was taken out of bug: http://bugs.python.org/issue1664 if that helps... platform: Linux hostnamehere 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 2008 i686 i686 i386 GNU/Linux morrowc at tweezer:/tmp$ diff -U3 nntplib.py.orig nntplib.py --- nntplib.py.orig 2008-12-30 01:06:14.000000000 -0500 +++ nntplib.py 2008-12-30 01:07:33.000000000 -0500 @@ -109,8 +109,19 @@ """ self.host = host self.port = port - self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) - self.sock.connect((self.host, self.port)) + msg = "getaddrinfo returns an empty list" + for res in socket.getaddrinfo(self.host, self.port, 0, socket.SOCK_STREAM): + af, socktype, proto, canonname, sa = res + sock = None + try: + self.sock = socket.socket(af, socktype, proto) + self.sock.connect(sa) + + except error, msg: + if self.sock is not None: + self.sock.close() + raise NNTPError, msg + self.file = self.sock.makefile('rb') self.debugging = 0 self.welcome = self.getresp() ---------- components: Library (Lib) files: nntplib.py-ipv6.patch keywords: patch messages: 78509 nosy: morrowc severity: normal status: open title: nntplib - python 2.5 type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file12489/nntplib.py-ipv6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 08:20:21 2008 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 30 Dec 2008 07:20:21 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230621621.36.0.135657761549.issue4750@psf.upfronthosting.co.za> anatoly techtonik added the comment: I attach for Python 2.5 as well. People will use gzip module for a long time to build packages and patch will help them to get correct archives. Added file: http://bugs.python.org/file12490/python25.issue4750.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 08:41:31 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 30 Dec 2008 07:41:31 +0000 Subject: [issue4701] range objects becomes hashable after attribute access In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za> Message-ID: <1230622891.44.0.697968360076.issue4701@psf.upfronthosting.co.za> Nick Coghlan added the comment: Forward port to 3.x: 3.1: r68058 3.0: r68060 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 09:47:02 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 08:47:02 +0000 Subject: [issue4775] Incorrect documentation - UTC time In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za> Message-ID: <4959E001.1080808@v.loewis.de> Martin v. L?wis added the comment: > The difference is that UTC includes leap seconds, whereas UT1 does not (see ). The > conversion routines ignore leap seconds, e.g., (time.mktime((2000,1,1,12,0,0,0,0,0))- > time.mktime((1990,1,1,12,0,0,0,0,0))) returns an exact multiple of > 24*60*60 and does not include all the leap seconds added between those > dates. Read the documentation carefully. It doesn't claim that mktime uses UTC, and claiming that it uses UT1 would be equally incorrect. Instead, mktime uses local time (as documented). Whether that includes leap seconds or not depends on the definition of your time zone in your operating system. Also notice that the Unix time (time_t) is discontinuous with respect to leap seconds; each day time_t advances by 86400 seconds even if there was a leap second on that day; see http://en.wikipedia.org/wiki/Unix_time So even if your time zone includes leap seconds, then mktime still correctly computes the difference as multiple of 86400. Which specific other usage of UTC do you also consider incorrect? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 09:56:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 08:56:39 +0000 Subject: [issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine In-Reply-To: <1221106076.33.0.246620485581.issue3833@psf.upfronthosting.co.za> Message-ID: <1221106076.33.0.246620485581.issue3833@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm seeing the same symptoms that are described in issue 1543 with the 2.6b3 MSIs. Namely, when you run one of the MSIs (either 32-bit or 64-bit) then the other will refuse to install. This is on XP Pro x64 SP2. python-3.0b3.msi and python-3.0b3.amd64.msi exhibit the same problem. Having 32-bit and 64-bit version coexist makes it much easier to build extensions for and test on both versions at the same time. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 09:58:46 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 08:58:46 +0000 Subject: [issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine In-Reply-To: <1221106076.33.0.246620485581.issue3833@psf.upfronthosting.co.za> Message-ID: <1230627526.45.0.520028427168.issue3833@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It is possible to reattach messages to the issue. In this specific case, just append ?@action=edit&@add at messages=73003 to the issue URL. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:04:57 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 09:04:57 +0000 Subject: [issue4096] Lib/lib2to3/*.pickle are shipped / modified in the build In-Reply-To: <1223623372.4.0.845692129772.issue4096@psf.upfronthosting.co.za> Message-ID: <1230627897.97.0.553706427585.issue4096@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's not sufficient that they get created when 2to3 needs them. It might be that the user running 2to3 has no permission to write them. I believe that it currently then just won't write them - but they won't be created, either (it used to be that it aborts when it can't write them) However, they should get installed with "make install" - so closing it as "works for me". ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:06:38 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 09:06:38 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230627998.05.0.386717004358.issue4750@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Removed file: http://bugs.python.org/file12452/tarfile.directory.fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:07:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 09:07:20 +0000 Subject: [issue4750] tarfile keeps excessive dir structure in compressed files In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za> Message-ID: <1230628040.68.0.20569365204.issue4750@psf.upfronthosting.co.za> Martin v. L?wis added the comment: No further bug fixes are accepted for 2.5 (unless they fix security problems), so I reject the 2.5 patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:41:23 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 09:41:23 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230630083.18.0.654600193028.issue4742@psf.upfronthosting.co.za> Changes by Tarek Ziad? : ---------- assignee: -> tarek nosy: +tarek priority: -> normal type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:55:39 2008 From: report at bugs.python.org (Dmitry Vasiliev) Date: Tue, 30 Dec 2008 09:55:39 +0000 Subject: [issue4778] Small typo in multiprocessing documentation In-Reply-To: <1230630939.22.0.804614674189.issue4778@psf.upfronthosting.co.za> Message-ID: <1230630939.22.0.804614674189.issue4778@psf.upfronthosting.co.za> New submission from Dmitry Vasiliev : Small typo about "call" Process.daemon flag. The patch attached. ---------- assignee: georg.brandl components: Documentation files: multiprocessing.patch keywords: patch messages: 78516 nosy: georg.brandl, hdima severity: normal status: open title: Small typo in multiprocessing documentation versions: Python 3.0 Added file: http://bugs.python.org/file12491/multiprocessing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 11:15:57 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Dec 2008 10:15:57 +0000 Subject: [issue4778] Small typo in multiprocessing documentation In-Reply-To: <1230630939.22.0.804614674189.issue4778@psf.upfronthosting.co.za> Message-ID: <1230632157.05.0.0024086941607.issue4778@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r68061. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 11:42:23 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 10:42:23 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230633743.74.0.253805126411.issue4742@psf.upfronthosting.co.za> Tarek Ziad? added the comment: Here's a status: The problem is located in the codec that decodes the data (called by the compile builtin). It throws an error : *** UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 853: character maps to Which is caught by compile and translated into: SyntaxError: unknown encoding: cp1252 So I see two problems: 1/ why compile throws such an error when there's an UnicodeDecodeError 2/ why compile works well under Py2 since 0x9d is not part of the cp1252 mapping I have written a test that reproduces the problem, and I am still investigating. If I can't find the problem I will ask for help on python-dev because I have no knowledge in the compiler internals yet. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 12:36:42 2008 From: report at bugs.python.org (pierre.lhoste) Date: Tue, 30 Dec 2008 11:36:42 +0000 Subject: [issue4779] Can't import Tkinter In-Reply-To: <1230637002.81.0.814497868167.issue4779@psf.upfronthosting.co.za> Message-ID: <1230637002.81.0.814497868167.issue4779@psf.upfronthosting.co.za> New submission from pierre.lhoste : I've just installed Python 3.0 (with Tkinter) on Windows Vista, but I can't import Tkinter : "No module named Tkinter" When installing Python 2.6, it works. Why ? Thank you. ---------- components: Tkinter messages: 78519 nosy: pierre.lhoste severity: normal status: open title: Can't import Tkinter versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 12:41:28 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Tue, 30 Dec 2008 11:41:28 +0000 Subject: [issue4779] Can't import Tkinter In-Reply-To: <1230637002.81.0.814497868167.issue4779@psf.upfronthosting.co.za> Message-ID: <1230637288.75.0.939813580608.issue4779@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: Tkinter has been renamed to tkinter (and been made a package) as part of the stdlib reorganisation : http://www.python.org/dev/peps/pep-3108/#tkinter-package ---------- nosy: +quentin.gallet-gilles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 12:54:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 11:54:22 +0000 Subject: [issue1011893] Problems importing packages in ZIP file Message-ID: <1230638062.13.0.0211788806325.issue1011893@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It seems most people agree that this "works for me". ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:14:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 12:14:52 +0000 Subject: [issue3997] zipfile and winzip In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za> Message-ID: <1230639292.71.0.00579035593408.issue3997@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:15:10 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 12:15:10 +0000 Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories properly In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za> Message-ID: <1230639310.85.0.24879586571.issue4710@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:20:30 2008 From: report at bugs.python.org (John Machin) Date: Tue, 30 Dec 2008 12:20:30 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230639630.73.0.892442560505.issue4742@psf.upfronthosting.co.za> John Machin added the comment: TWO POINTS: (1) I am not very concerned about chars like \x9d which are not valid in the declared encoding; I am more concerned with chars like \x93 and \x94 which *ARE* valid in the declared encoding. Please ensure that these cases are included in tests. (2) Please check your test data and test results. I get different results. I have created a file x9d.py by making the minimal changes to x94.py. For me, this blows up on bytecompiling with *both* 3.0 (UnicodeDecodeError, as expected) and 2.x (Syntax Error unknown encoding cp1252, wrong message) -- see below. byte-compiling C:\python30\Lib\site-packages\x9d.py to x9d.pyc Traceback (most recent call last): File "setup.py", line 5, in py_modules = ["foo3", "bar3", "x93", "x94", "x9d", "xa0b7"] File "C:\python30\lib\distutils\core.py", line 149, in setup dist.run_commands() File "C:\python30\lib\distutils\dist.py", line 942, in run_commands self.run_command(cmd) File "C:\python30\lib\distutils\dist.py", line 962, in run_command cmd_obj.run() File "C:\python30\lib\distutils\command\install.py", line 571, in run self.run_command(cmd_name) File "C:\python30\lib\distutils\cmd.py", line 317, in run_command self.distribution.run_command(command) File "C:\python30\lib\distutils\dist.py", line 962, in run_command cmd_obj.run() File "C:\python30\lib\distutils\command\install_lib.py", line 91, in run self.byte_compile(outfiles) File "C:\python30\lib\distutils\command\install_lib.py", line 125, in byte_compile dry_run=self.dry_run) File "C:\python30\lib\distutils\util.py", line 520, in byte_compile compile(file, cfile, dfile) File "C:\python30\lib\py_compile.py", line 137, in compile codestring = f.read() File "C:\python30\lib\io.py", line 1724, in read decoder.decode(self.buffer.read(), final=True)) File "C:\python30\lib\io.py", line 1295, in decode output = self.decoder.decode(input, final=final) File "C:\python30\lib\encodings\cp1252.py", line 23, in decode return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 64: character maps to byte-compiling C:\python26\Lib\site-packages\x9d.py to x9d.pyc SyntaxError: ('unknown encoding: cp1252', ('C:\\python26\\Lib\\site-packages\\x9d.py', 0, 0, None)) byte-compiling c:\python25\Lib\site-packages\x9d.py to x9d.pyc File "c:\python25\Lib\site-packages\x9d.py", line 0 SyntaxError: ('unknown encoding: cp1252', ('c:\\python25\\Lib\\site-packages\\x9d.py', 0, 0, None)) Added file: http://bugs.python.org/file12492/x9d.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:21:59 2008 From: report at bugs.python.org (David Morley) Date: Tue, 30 Dec 2008 12:21:59 +0000 Subject: [issue4775] Incorrect documentation - UTC time In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za> Message-ID: <1230639719.65.0.526237015883.issue4775@psf.upfronthosting.co.za> David Morley added the comment: - My use of mktime was a bad choice for an example, since "local time" is not defined and does not necessarily bear any relationship to UTC. However the documentation does claim that time.gmtime converts "a time expressed in seconds since the epoch" to "a struct_time in UTC". - You are no doubt correct that under Unix, "Unix time" is actually used, however the phrase "a time expressed in seconds since the epoch" implies the number of *elapsed* seconds since the epoch, which is not the same thing as Unix time. It was the fact that (at least under Mac OS X) the numeric representation assumes a 86400 second day that led me to believe that non-SI seconds and hence a non-UTC version of Universal Time, such as UT1 was being used. The documentation should make it clear either that (1) the numeric representation of times is based on Unix time and assumes a 86400 SI second day, and therefore (1a) the number of elapsed SI seconds between two numeric times is not necessarily equal to the difference of those two numbers and (1b) gmtime accurately converts a UTC time, or that (2) the numeric representation of times is based on a 86400 non-SI second day, and therefore (2a) the number of elapsed (non-SI) seconds between two numeric times is equal to the difference of the two numbers and (2b) gmtime accurately converts a non-UTC Universal Time, or that (3) the numeric representation of times is based on TAI and assumes a 86400 SI second day, and therefore (1a) the number of elapsed SI seconds between two numeric times is equal to the difference of those two numbers and (1b) gmtime accurately converts a TAI time, or that (4) the numeric representation of time is based on SI-seconds past the epoch and allows variable length days, and therefore (4a) the number of elapsed SI seconds between two numeric times is equal to the difference of the two numbers and (4b) gmtime only accurately converts a UTC time that is before the next future leap-second adjustment (whenever that may be), or that (5) the numeric representation of time is platform-dependent and any one of the above may hold. Note that the only significant difference in implementation between (1), (2), and (3) is what time.time() actually returns: Unix time, a non-UTC Universal Time, or TAI. Since the time.localtime is most-likely implemented as an integral- minute offset from time.gmtime, the same issues arise for time.localtime and time.mktime. The same documentation issue crops up in and indirectly (calendar.timegm) in _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:41:37 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 30 Dec 2008 12:41:37 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230639630.73.0.892442560505.issue4742@psf.upfronthosting.co.za> Message-ID: <495A16FE.1030001@egenix.com> Marc-Andre Lemburg added the comment: On 2008-12-30 13:20, John Machin wrote: > byte-compiling C:\python26\Lib\site-packages\x9d.py to x9d.pyc > SyntaxError: ('unknown encoding: cp1252', > ('C:\\python26\\Lib\\site-packages\\x9d.py', 0, 0, None)) > > byte-compiling c:\python25\Lib\site-packages\x9d.py to x9d.pyc > File "c:\python25\Lib\site-packages\x9d.py", line 0 > SyntaxError: ('unknown encoding: cp1252', > ('c:\\python25\\Lib\\site-packages\\x9d.py', 0, 0, None)) > > Added file: http://bugs.python.org/file12492/x9d.py FWIW, I've tried that file with Python 2.5 and 2.6 on my machine: lemburg/tmp> python2.5 ~/bin/pycompile.py x9d.py compiling x9d.py -> x9d.pyc XXX : unknown encoding: cp1252 (x9d.py, line 0) lemburg/tmp> python2.6 ~/bin/pycompile.py x9d.py compiling x9d.py -> x9d.pyc XXX : unknown encoding: cp1252 (x9d.py, line 0) Note that the line number is wrong in both messages. It is interesting that simply running the files gives a more correct error message: lemburg/tmp> python2.5 x9d.py File "x9d.py", line 2 SyntaxError: 'charmap' codec can't decode byte 0x9d in position 0: character maps to lemburg/tmp> python2.6 x9d.py File "x9d.py", line 2 SyntaxError: 'charmap' codec can't decode byte 0x9d in position 0: character maps to The character position is wrong again in both messages. Needless to say that the encoding "cp1252" is *not* unknown. It looks like compile() causes the decoding error to be overwritten with a misleading error message. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:44:05 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 12:44:05 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230641045.84.0.970460649264.issue4742@psf.upfronthosting.co.za> Tarek Ziad? added the comment: yup, here's the test I have written to demonstrate the problem. In any case, compile doesn't behave right way in the first place. ---------- keywords: +patch Added file: http://bugs.python.org/file12493/encoding.issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:44:43 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 12:44:43 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230641083.98.0.807168292656.issue4742@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file12493/encoding.issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:45:00 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 12:45:00 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230641100.83.0.572247341713.issue4742@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Added file: http://bugs.python.org/file12494/encoding.issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:58:50 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 12:58:50 +0000 Subject: [issue4702] [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError In-Reply-To: <1229722389.12.0.525860035611.issue4702@psf.upfronthosting.co.za> Message-ID: <1230641930.68.0.369924321719.issue4702@psf.upfronthosting.co.za> Changes by Tarek Ziad? : ---------- assignee: -> tarek nosy: +tarek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:06:18 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 13:06:18 +0000 Subject: [issue4780] Makefile.pre.in patch to run regen on OSX (framework build) In-Reply-To: <1230642378.46.0.486113805886.issue4780@psf.upfronthosting.co.za> Message-ID: <1230642378.46.0.486113805886.issue4780@psf.upfronthosting.co.za> New submission from Ronald Oussoren : I needed the attached patch to install a framework build of Python3 (py3k branch), otherwise the 'regen' script wouldn't start to build Lib/plat- mac. I haven't applied the patch to the repository because I don't know if there's a reason for not using RUNSHARED in the first place. ---------- components: Build files: Makefile.pre.in.patch keywords: needs review, patch, patch messages: 78526 nosy: ronaldoussoren priority: normal severity: normal status: open title: Makefile.pre.in patch to run regen on OSX (framework build) versions: Python 3.1 Added file: http://bugs.python.org/file12495/Makefile.pre.in.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:13:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 13:13:32 +0000 Subject: [issue4775] Incorrect documentation - UTC time In-Reply-To: <1230639719.65.0.526237015883.issue4775@psf.upfronthosting.co.za> Message-ID: <495A1E77.6010108@v.loewis.de> Martin v. L?wis added the comment: > It was the fact that (at least under Mac OS X) the numeric > representation assumes a 86400 second day that led me to > believe that non-SI seconds and hence a non-UTC version of Universal > Time, such as UT1 was being used. AFAICT, Mac OSX also uses Unix time... Why do you think UT1 plays any role here? Computers *have* to use SI seconds, since they are not physically equipped to measure anything else (unless you want to get even more nit-picking and point out that the quartz in the computer is not capable of measuring SI seconds exactly). > (5) the numeric representation of time is platform-dependent This is the case. > and any one of the above may hold. This is not consequential. As it is platform dependent, it might do any of the above, plus an infinite number of additional alternatives (including bugs and whatnot). I propose to add this sentence to the explanation of the epoch: "It is platform-dependent whether or not 'seconds since the epoch' includes leap seconds. Most systems likely implement `Unix time`_" _ http://en.wikipedia.org/wiki/Unix_time > The same documentation issue crops up in > and indirectly > (calendar.timegm) in Please, one issue at a time. I believe that this doesn't crop up, or if it does, it's a different issue. If you want to pursue this, please create a separate report, and preferably include a proposed wording. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:16:41 2008 From: report at bugs.python.org (John Machin) Date: Tue, 30 Dec 2008 13:16:41 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230643001.2.0.378290953868.issue4742@psf.upfronthosting.co.za> John Machin added the comment: (1) what am I supposed to infer from "Yup"?? That all of that \x9d stuff was a mistake? (2) + def tearDown(self): + pyc_file = os.path.join(os.path.dirname(__file__), 'cp1252.pyc') + if os.path.exists(pyc_file): + os.patth.remove(pyc_file) os.patth is novel :-) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:24:16 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 13:24:16 +0000 Subject: [issue4755] Common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1230643456.4.0.304808972241.issue4755@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The documentation should explain what a "common path prefix" is. It can't be the path to a common parent directory, since the new function doesn't allow mixing absolute and relative directories. As Phillip Eby points out, it also doesn't account for case-insensitivity that some file systems or operating systems implement, nor does it take into account short file names on Windows. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:28:18 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 13:28:18 +0000 Subject: [issue4075] Use WCHAR variant of OutputDebugString In-Reply-To: <1223471607.48.0.166278298943.issue4075@psf.upfronthosting.co.za> Message-ID: <1230643698.28.0.625092985329.issue4075@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:28:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 13:28:49 +0000 Subject: [issue4075] Use WCHAR variant of OutputDebugString In-Reply-To: <1223471607.48.0.166278298943.issue4075@psf.upfronthosting.co.za> Message-ID: <1230643729.78.0.0879362000107.issue4075@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:31:01 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 13:31:01 +0000 Subject: [issue4075] Use WCHAR variant of OutputDebugString In-Reply-To: <1223471607.48.0.166278298943.issue4075@psf.upfronthosting.co.za> Message-ID: <1230643861.39.0.0772740294192.issue4075@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- assignee: -> loewis priority: -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:31:24 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Dec 2008 13:31:24 +0000 Subject: [issue4051] UNICODE macro in cPickle conflicts with Windows define In-Reply-To: <1223288926.88.0.428745871562.issue4051@psf.upfronthosting.co.za> Message-ID: <1230643884.9.0.0552413994656.issue4051@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- assignee: -> loewis priority: -> high resolution: -> accepted stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:51:27 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 30 Dec 2008 13:51:27 +0000 Subject: [issue4755] Common path prefix In-Reply-To: <1230643456.4.0.304808972241.issue4755@psf.upfronthosting.co.za> Message-ID: <18778.10074.528218.720379@montanaro-dyndns-org.local> Skip Montanaro added the comment: I think we need to recognize the inherent limitations of what we can expect to do. It is perfectly reasonable for a user on Windows to import posixpath and call posixpath.commonpathprefix. The function won't have access to the actual filesystems being manipulated. Same for Unix folks importing ntpath and manipulating Windows paths. While we can make it handle case-insensitivity, I'm no sure we can do much, if anything, about shortened filenames. Also, as long as we are considering case sensitivity, what about HFS on Mac OS X? Skip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:55:32 2008 From: report at bugs.python.org (Matthew Karas) Date: Tue, 30 Dec 2008 13:55:32 +0000 Subject: [issue3872] Python 2.6rc2: Tix ComboBox error In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za> Message-ID: <1230645332.56.0.364700612664.issue3872@psf.upfronthosting.co.za> Matthew Karas added the comment: I'm sorry, will this fix get into a new release? I tried using a tix widget on 2.6.1 and got the same error. ---------- nosy: +lucidguppy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:55:42 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 30 Dec 2008 13:55:42 +0000 Subject: [issue4755] Common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1230645342.3.0.0583669451709.issue4755@psf.upfronthosting.co.za> Nick Coghlan added the comment: 1. The discussion on python-dev shows that the current documentation of os.path.commonprefix is incorrect - it technically works element by element rather than character by character (since it will handle sequences other than strings, such as lists of path components) 2. Splitting on os.sep is not the correct way to break a string into path components. Instead, os.path.split needs to be applied repeatedly until "head" is a single character (a single occurrence of os.sep or os.altsep for an absolute path) or empty (for a relative path). (Alternatively, but with additional effects on the result, the separators can be normalised first with os.path.normpath or os.path.normcase) For Windows, os.path.splitunc and os.path.splitdrive should also be invoked first, and if either returns a non-empty string, that should become the first path component (with the remaining components filled in as above) 3. Calling any or all of abspath/expanduser/expandvars/normcase/normpath/realpath is the responsibility of the library user as far as os.path.commonprefix is concerned. Should that behaviour be retained for an os.path.commonpath function, or should some of them (such as os.path.abspath) be called automatically? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:05:13 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 30 Dec 2008 14:05:13 +0000 Subject: [issue4755] Common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1230645913.12.0.963352373292.issue4755@psf.upfronthosting.co.za> Nick Coghlan added the comment: The regex based approach to the component splitting when os.altsep is defined obviously works as well. Duplicating the values of sep and altsep in the default regex that way grates a little though... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:37:19 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 30 Dec 2008 14:37:19 +0000 Subject: [issue4626] compile() doesn't ignore the source encoding when a string is passed in In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za> Message-ID: <1230647839.23.0.204632416565.issue4626@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Issue4742 is similar issue: >>> source = b"# coding=cp1252\n\x94 = '\x94'".decode('cp1252') >>> compile(source, '', 'exec') Traceback (most recent call last): File "", line 1, in File "", line 0 SyntaxError: unknown encoding: cp1252 The real error here is masked; just before the exception is set, there is a pending SyntaxError: 'charmap' codec can't decode byte 0x9d in position 18: character maps to It seems that the source internal representation is correct utf-8, but this is decoded again with the "coding=" cookie. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:38:03 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 30 Dec 2008 14:38:03 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230647883.5.0.881475748077.issue4742@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This is a duplicate of issue4626. Here, the content is correctly decoded with cp1252, then passed to compile(); but compile() works on the internal utf-8 representation, and tries to decode it again with cp1252! Yes, the error message is overwritten. If I remove the code that sets the "unknown encoding" exception, I get: >>> compile(open("c:/temp/t1252.py", encoding="cp1252").read(), "t1252.py", "exec") SyntaxError: 'charmap' codec can't decode byte 0x9d in position 35: character maps to The 0x9d explains easily: >>> b"\x94".decode('cp1252').encode('utf8') b'\xe2\x80\x9d' ---------- nosy: +amaury.forgeotdarc superseder: -> compile() doesn't ignore the source encoding when a string is passed in _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:47:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Dec 2008 14:47:13 +0000 Subject: [issue4779] Can't import Tkinter In-Reply-To: <1230637002.81.0.814497868167.issue4779@psf.upfronthosting.co.za> Message-ID: <1230648433.56.0.214846834394.issue4779@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:47:15 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 14:47:15 +0000 Subject: [issue4472] Is shared lib building broken on trunk? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230648435.21.0.206428079101.issue4472@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The issue is caused by lack of support for building .dylibs in configure.in and Makefile.pre.in. AFAIK this has never worked on OSX. Fixing that is not entirely trivial (did I mention configure.in is rather crufty?). The attached patch should fix that (the patch touched configure.in, you'll have to run autoconf after applying the patch). Could you please test if the patch fixes the issue for you? ---------- keywords: +patch nosy: +ronaldoussoren Added file: http://bugs.python.org/file12496/issue4472.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:52:23 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 14:52:23 +0000 Subject: [issue4554] Missing make altframeworkinstall for Mac OS X In-Reply-To: <1228525462.29.0.299893265835.issue4554@psf.upfronthosting.co.za> Message-ID: <1230648743.99.0.68295565295.issue4554@psf.upfronthosting.co.za> Ronald Oussoren added the comment: "make frameworkinstall" should be deprecated anyway, AFAIK it should be possible to use "make install" or "make altinstall" for framework installs as well. That latter should make it possible to install multiple versions of python side-by-side without interference beyond the "Current" link inside the framework. A patch to fix that last issue would be welcome ;-) BTW. The above comment is for python 2.x, I haven't checked the makefiles for python 3.x yet beyond trying to get a framework build to work at all (commited a patch for that earlier today). ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:53:42 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 14:53:42 +0000 Subject: [issue1738250] Universal MacPython 2.5.1 installation fails Message-ID: <1230648822.99.0.580194661115.issue1738250@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Can you reproduce this problem with the installer for Python 2.6? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 16:07:18 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 15:07:18 +0000 Subject: [issue4472] Is shared lib building broken on trunk? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230649638.6.0.485473733351.issue4472@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Never mind, the patch won't work. Python's build procedure on unix-y platforms assumes that the suffix for shared libraries is the same as that for python extentions. That's not true on OSX :-( I'm working on an updated patch. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 16:15:51 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 15:15:51 +0000 Subject: [issue4472] Is shared lib building broken on trunk? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230650151.5.0.173992696476.issue4472@psf.upfronthosting.co.za> Changes by Ronald Oussoren : Removed file: http://bugs.python.org/file12496/issue4472.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 16:44:02 2008 From: report at bugs.python.org (Deli.Zhang) Date: Tue, 30 Dec 2008 15:44:02 +0000 Subject: [issue4781] The function, Threading.Timer.run(), may be Inappropriate In-Reply-To: <1230651841.99.0.415726342941.issue4781@psf.upfronthosting.co.za> Message-ID: <1230651841.99.0.415726342941.issue4781@psf.upfronthosting.co.za> New submission from Deli.Zhang : def run(self): self.finished.wait(self.interval) if not self.finished.isSet(): self.function(*self.args, **self.kwargs) self.finished.set() I think the function run() should be modified to like this below: def run(self): while not self.finished.isSet(): self.finished.wait(self.interval) self.function(*self.args, **self.kwargs) In this case, it can still run on next 'interval', and next's next... ---------- components: Library (Lib) messages: 78540 nosy: gestapo21th severity: normal status: open title: The function, Threading.Timer.run(), may be Inappropriate type: feature request versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 16:49:08 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 15:49:08 +0000 Subject: [issue4472] Is shared lib building broken on trunk? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230652148.02.0.582052311781.issue4472@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I've uploaded a new version of issue4472.patch that seems to do the trick: this supports --enable-shared and also still works without that flag. Added file: http://bugs.python.org/file12497/issue4472.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:01:49 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 30 Dec 2008 16:01:49 +0000 Subject: [issue4782] json documentation missing load(), loads() In-Reply-To: <1230652909.54.0.874688686508.issue4782@psf.upfronthosting.co.za> Message-ID: <1230652909.54.0.874688686508.issue4782@psf.upfronthosting.co.za> New submission from David M. Beazley : Documentation for the json module in Python 2.6 and Python 3.0 doesn't have any description for load() or loads() even though both functions are used in the examples. ---------- assignee: georg.brandl components: Documentation messages: 78542 nosy: beazley, georg.brandl severity: normal status: open title: json documentation missing load(), loads() versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:20:09 2008 From: report at bugs.python.org (Roumen Petrov) Date: Tue, 30 Dec 2008 16:20:09 +0000 Subject: [issue4472] Is shared lib building broken on trunk? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230654009.62.0.0937248065228.issue4472@psf.upfronthosting.co.za> Roumen Petrov added the comment: What is reason to change SO to ".dylib" in configure script and later Lib/distutils/sysconfig.py to restore it to ".so" ? Also other builds use $(LDSHARED) to create python shared library. Why proposed patch introduce inconsistency with other builds and ignore LDSHARED set by configure script ? ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:24:10 2008 From: report at bugs.python.org (Roumen Petrov) Date: Tue, 30 Dec 2008 16:24:10 +0000 Subject: [issue4472] Is shared lib building broken on trunk? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230654250.04.0.104339280383.issue4472@psf.upfronthosting.co.za> Roumen Petrov added the comment: Skip, Why the issue title is without platform? Shared build is fine on Linux and Cygwin too. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:31:12 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 30 Dec 2008 16:31:12 +0000 Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230654672.85.0.592483807138.issue4472@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- title: Is shared lib building broken on trunk? -> Is shared lib building broken on trunk for Mac OS X? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:32:41 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 16:32:41 +0000 Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230654760.91.0.582200195124.issue4472@psf.upfronthosting.co.za> Ronald Oussoren added the comment: "SO=.dylib" is needed in the makefile to ensure that "make install" works and to ensure that the libpython shared library is build with the right suffix (OSX uses .dylib for shared libraries). The code in distutils.sysconfig is necessary to ensure that extentions are build with a ".so" suffix because the import machinery expected '.so' as the suffix. BTW. I intent to commit the attached patch later this week. ---------- resolution: -> accepted versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:59:46 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2008 16:59:46 +0000 Subject: [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za> Message-ID: <1230656386.39.0.580048684981.issue4263@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The tests should be written so as not to rely on internal implementation details (the _write_buf attribute). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 18:13:37 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 17:13:37 +0000 Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252 In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za> Message-ID: <1230657217.37.0.992227410133.issue4742@psf.upfronthosting.co.za> Changes by Tarek Ziad? : ---------- resolution: -> duplicate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 18:16:50 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 30 Dec 2008 17:16:50 +0000 Subject: [issue4783] json documentation needs a BAWM (Big A** Warning Message) In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za> Message-ID: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za> New submission from David M. Beazley : The json module is described as having an interface similar to pickle: json.dump() json.dumps() json.load() json.loads() I think it would be a WISE idea to add a huge warning message to the documentation that these functions should *NOT* be used to serialize or unserialize multiple objects on the same file stream like pickle. For example: f = open("stuff","w") json.dump(obj1, f) json.dump(obj2, f) # NO! FLAMING DEATH! f = open("stuff","r") obj1 = json.load(f) obj2 = json.load(f) # NO! EXTRA CRIPSY FLAMING DEATH! For one, it doesn't work. load() actually reads the whole file into a big string and tries to parse it as a single object. If there are multiple objects in the file, you get a nasty exeption. Second, I'm not even sure this is technically allowed by the JSON spec. As far as I call tell, concatenating JSON objects together in the same file falls into the same category as concatenating two HTML documents together in the same file (something you just don't do). Related: json.load() should probably not be used on any streaming input source such as a file wrapped around a socket. The first thing it does is consume the entire input by calling f.read()---which probably not what someone is expecting (and it might even cause the whole program to hang). ---------- assignee: georg.brandl components: Documentation messages: 78547 nosy: beazley, georg.brandl severity: normal status: open title: json documentation needs a BAWM (Big A** Warning Message) type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 18:17:41 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2008 17:17:41 +0000 Subject: [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za> Message-ID: <1230657461.71.0.27362139621.issue4263@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch which replaces testWriteNonBlocking with a reasonable implementation-independent test (it works with e.g. the io-c sandbox). The new test also checks for the current problem, i.e. it passes with the fix to io.py and fails without. Added file: http://bugs.python.org/file12498/nonblocking.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 18:23:10 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 30 Dec 2008 17:23:10 +0000 Subject: [issue4783] json documentation needs a BAWM (Big A** Warning Message) In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za> Message-ID: <1230657790.73.0.428471890273.issue4783@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: georg.brandl -> bob.ippolito nosy: +bob.ippolito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 18:41:46 2008 From: report at bugs.python.org (Eric Naeseth) Date: Tue, 30 Dec 2008 17:41:46 +0000 Subject: [issue4784] Mismatch in documentation for module "webbrowser" In-Reply-To: <1230658906.5.0.498985661284.issue4784@psf.upfronthosting.co.za> Message-ID: <1230658906.5.0.498985661284.issue4784@psf.upfronthosting.co.za> New submission from Eric Naeseth : In Python 2.5, a new method named "open_new_tab" was added to webbrowser and webbrowser's browser controller objects. With this addition, there are now three methods on browser controllers, but the documentation still reads: "Browser controllers provide two methods which parallel *two* of the module-level convenience functions". ---------- assignee: georg.brandl components: Documentation messages: 78549 nosy: georg.brandl, improper_smile severity: normal status: open title: Mismatch in documentation for module "webbrowser" versions: Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 18:42:14 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 30 Dec 2008 17:42:14 +0000 Subject: [issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za> Message-ID: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za> New submission from David M. Beazley : The strict parameter to JSONDecoder() is undocumented and is confusing because someone might assume it has something to do with the encoding parameter or the general handling of parsing errors (which it doesn't). As far as I can determine by reading the source, strict determines whether or not JSON strings are allowed to contain literal newlines in them or not. For example (note: loads() passes its parameters to JSONDecoder): >>> s = '{"test":"Hello\nWorld"}' >>> print(s) {"test":"Hello World"} >>> json.loads(s) Traceback (most recent call last): ... File "/tmp/lib/python3.0/json/decoder.py", line 159, in JSONString return scanstring(match.string, match.end(), encoding, strict) ValueError: Invalid control character at: line 1 column 14 (char 14) >>> json.loads(s,strict=False) {'test': 'Hello\nWorld'} >>> Note in this last example how the result has the literal newline embedded in it when strict is set False. ---------- assignee: georg.brandl components: Documentation messages: 78550 nosy: beazley, georg.brandl severity: normal status: open title: json.JSONDecoder() strict argument undocumented and potentially confusing type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:00:55 2008 From: report at bugs.python.org (Roumen Petrov) Date: Tue, 30 Dec 2008 18:00:55 +0000 Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230660055.56.0.976507937007.issue4472@psf.upfronthosting.co.za> Roumen Petrov added the comment: Ronald, In proposed patch we see (insert about line 740): + LDLIBRARY='libpython$(VERSION).dylib' + BLDLIBRARY='-L. -lpython$(VERSION)' + RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH}' Let see comment in configure script(about line 585): # MacOSX framework builds need more magic. LDLIBRARY is the dynamic # library that we build, but we do not want to link against it (we # will find it with a -framework option). For this reason there is an # extra variable BLDLIBRARY against which Python and the extension # modules are linked, BLDLIBRARY. This is normally the same as # LDLIBRARY, but empty for MacOSX framework builds. Next on line about 675 we see: # MacOSX framework builds need more magic. LDLIBRARY is the dynamic # library that we build, but we do not want to link against it (we # will find it with a -framework option). For this reason there is an # extra variable BLDLIBRARY against which Python and the extension # modules are linked, BLDLIBRARY. This is normally the same as # LDLIBRARY, but empty for MacOSX framework builds. if test "$enable_framework" then LDLIBRARY='$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)' RUNSHARED=DYLD_FRAMEWORK_PATH="`pwd`:$DYLD_FRAMEWORK_PATH" BLDLIBRARY='' else BLDLIBRARY='$(LDLIBRARY)' fi So proposed patch is not consistent with comments. Is expected shared build to ignore framework build ? About "SO" - as I understand python build system it is reserved for module suffix. So there is no reason to change it. About .dylib - I'm sure that issue can be resolved with appropriate update without SO to be changed by configure. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:06:49 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 30 Dec 2008 18:06:49 +0000 Subject: [issue4780] Makefile.pre.in patch to run regen on OSX (framework build) In-Reply-To: <1230642378.46.0.486113805886.issue4780@psf.upfronthosting.co.za> Message-ID: <1230660409.96.0.797452956862.issue4780@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I probably forgot to add it when I was missing with the Makefile a while back. I applied your patch in r68075. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:29:39 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2008 18:29:39 +0000 Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230661779.64.0.863073288709.issue4472@psf.upfronthosting.co.za> Ronald Oussoren added the comment: A --enable-framework and --enable-shared are mutable exclusive. You either have a regular unix build or a Python.framework. As to the SO update: the only way to avoid my change is yet another variable in the makefile. The "altbininstall" target assumes that it will install a shared library named "libpython$(VERSION)$(SO)". I haven't looked for other uses of the SO variable in the Makefiles yet. Is there any documentation on what the role of the "SO" variable means. If there isn't I propose to leave my patch as it is. The build infrastructure is complicated enough as it is. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:30:32 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 30 Dec 2008 18:30:32 +0000 Subject: [issue4769] b64decode should accept strings or bytes In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za> Message-ID: <1230661832.97.0.502272701907.issue4769@psf.upfronthosting.co.za> David M. Beazley added the comment: One more followup. The quopri module (which is highly related to base64 in that quopri and base64 are often used together within MIME) does accept both unicode and byte strings when decoding. For example, this works: >>> quopri.decodestring('Hello World') b'Hello World' >>> quopri.decodestring(b'Hello World') b'Hello World' >>> However, the quopri module, like base64, uses byte strings almost everywhere else. For example, encoding a byte string with quopri still produces bytes (just like base64) >>> quopri.encodestring(b'Hello World') b'Hello World' >>> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:42:33 2008 From: report at bugs.python.org (Bob Ippolito) Date: Tue, 30 Dec 2008 18:42:33 +0000 Subject: [issue4783] json documentation needs a BAWM (Big A** Warning Message) In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za> Message-ID: <1230662553.99.0.967177546225.issue4783@psf.upfronthosting.co.za> Bob Ippolito added the comment: You're the first person to ever raise any of these issues in the slightly more than 3 years that the package has been around (by other names), so I'm not sure such a warning needs to be that big. JSON doesn't really have any framing, so serializing more than one document to or from the same place doesn't work so well. It's not even talked about in the spec, and I've never seen someone try it before. ---------- priority: -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 20:02:17 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 30 Dec 2008 19:02:17 +0000 Subject: [issue4783] json documentation needs a BAWM (Big A** Warning Message) In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za> Message-ID: <1230663737.27.0.428873957175.issue4783@psf.upfronthosting.co.za> David M. Beazley added the comment: Just consider me to be an impartial outside reviewer. Hypothetically, let's say I'm a Python programmer who knows a thing or two about standard library modules (like pickle), but I'm new to JSON so I come looking at the json module documentation. The documentation tells me it uses the same interface as pickle and marshal (even naming those two modules right off the bat). So, right away, I'm thinking the module probably does all of the usual things that pickle and marshal can do. For instance, serializing multiple objects to the same stream. However, it doesn't work this way and the only way to find out that it doesn't work is to either try it and get an error, or to read the source code and figure it out. I'm not reporting this as an end-user of the json module, but as a Python book author who is trying to get things right and to be precise. I think if you're going to keep the pickle and marshal reference I would add the warning message. Otherwise, I wouldn't mention pickle or marshal at all. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 21:30:36 2008 From: report at bugs.python.org (Bob Ippolito) Date: Tue, 30 Dec 2008 20:30:36 +0000 Subject: [issue4783] json documentation needs a BAWM (Big A** Warning Message) In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za> Message-ID: <1230669036.74.0.253806170323.issue4783@psf.upfronthosting.co.za> Bob Ippolito added the comment: Ok, I've added some notes to the trunk of simplejson's documentation. Not sure when/if that'll hit the Python trunks, I've been having a hard time getting my other patches to sync up with simplejson through: http://bugs.python.org/issue4136 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 21:37:56 2008 From: report at bugs.python.org (Bob Ippolito) Date: Tue, 30 Dec 2008 20:37:56 +0000 Subject: [issue4782] json documentation missing load(), loads() In-Reply-To: <1230652909.54.0.874688686508.issue4782@psf.upfronthosting.co.za> Message-ID: <1230669476.07.0.0199348446748.issue4782@psf.upfronthosting.co.za> Bob Ippolito added the comment: There are some missing colons in the documentation apparently, which causes reStructuredText to ignore the documentation for those two functions. ---------- nosy: +bob.ippolito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 21:49:57 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 30 Dec 2008 20:49:57 +0000 Subject: [issue4783] json documentation needs a BAWM (Big A** Warning Message) In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za> Message-ID: <1230670197.08.0.624207528346.issue4783@psf.upfronthosting.co.za> David M. Beazley added the comment: Thanks! Hopefully I'm not giving you too much work to do :-). Cheers, Dave _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 22:28:04 2008 From: report at bugs.python.org (John Machin) Date: Tue, 30 Dec 2008 21:28:04 +0000 Subject: [issue4626] compile() doesn't ignore the source encoding when a string is passed in In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za> Message-ID: <1230672484.64.0.649750787528.issue4626@psf.upfronthosting.co.za> Changes by John Machin : ---------- nosy: +sjmachin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 22:53:00 2008 From: report at bugs.python.org (David M. Beazley) Date: Tue, 30 Dec 2008 21:53:00 +0000 Subject: [issue4786] xml.etree.ElementTree module name in Python 3 In-Reply-To: <1230673980.62.0.10201205304.issue4786@psf.upfronthosting.co.za> Message-ID: <1230673980.62.0.10201205304.issue4786@psf.upfronthosting.co.za> New submission from David M. Beazley : Not a bug, but a question to developers: Is xml.etree.ElementTree going to be the only standard library module in Python 3.0 that doesn't follow the standard Python 3.0 module naming conventions? (e.g., socketserver, configparser, etc.). Are there any plans to rename it to xml.etree.elementtree? Just curious. ---------- components: Library (Lib) messages: 78560 nosy: beazley severity: normal status: open title: xml.etree.ElementTree module name in Python 3 versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 23:22:00 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Tue, 30 Dec 2008 22:22:00 +0000 Subject: [issue4074] Building a list of tuples has non-linear performance In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za> Message-ID: <1230675720.83.0.204902240307.issue4074@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 23:25:44 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Tue, 30 Dec 2008 22:25:44 +0000 Subject: [issue4688] GC optimization: don't track simple tuples and dicts In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za> Message-ID: <1230675944.66.0.806833202295.issue4688@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 23:38:17 2008 From: report at bugs.python.org (Roumen Petrov) Date: Tue, 30 Dec 2008 22:38:17 +0000 Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230676697.66.0.935950532587.issue4472@psf.upfronthosting.co.za> Roumen Petrov added the comment: > A --enable-framework and --enable-shared are mutable exclusive. You > either have a regular unix build or a Python.framework. May be configure has to block user if both are enabled. > Is there any documentation on what the role of the "SO" variable means. Reading the code (distutils), comments configure script we may get some information. >From configure (line about 1600) : AC_DEFINE_UNQUOTED(SHLIB_EXT, "$SO", [Define this to be extension of shared libraries (including the dot!).]) Actually this is suffix for python module (as example for windows ".pyd" or "_d.pyd") If SO is changed by to .dylib for OS X in configure above line will define SHLIB_EXT to ".dylib" in "pyconfig.h". Ronald, you patch restore indirectly shared_lib_extension (distutils) to ".so", but define SHLIB_EXT from "pyconfig.h" will be ".dylib". This may impact other projects. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 23:54:48 2008 From: report at bugs.python.org (Lowell Alleman) Date: Tue, 30 Dec 2008 22:54:48 +0000 Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za> Message-ID: <1230677688.04.0.0203819261483.issue4749@psf.upfronthosting.co.za> Lowell Alleman added the comment: I've ran into the same problem before. I've found that due to differences between the way Unix and Windows handles files (inodes vs file handles), this problem is more apparent on Windows, but it isn't handled 100% correctly on Unix systems either. I think the root of the problem is that there is nothing in the code to handle multiple concurrent processes writing to a single log file; and I'm not sure there is a simple fix for this. I tried several easy solutions to this problem by retrying failed file renames and re-opening closed files, but I ultimately discovered all all such approaches are inadequate and can actually result in losing old log files too (in the worse-case scenario). I final got frustrated enough to just take the time to write my own. It is based on the built-in one and aims to be a "drop-in" replacement. I use file locking to safely write to a single log file from multiple python processes concurrently. If you would like to give it a try, it is located here: http://pypi.python.org/pypi/ConcurrentLogHandler I agree that it would be nice for the built in logging handlers to do this for you, but in the mean time this may be option for you. ---------- nosy: +lowell87 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 23:57:43 2008 From: report at bugs.python.org (Damian) Date: Tue, 30 Dec 2008 22:57:43 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> New submission from Damian : Hi, in switching to Python 3.0 I've run into an issue with displaying Unicode characters via curses. In Python 2.x a simple hello-world looks like: #!/usr/bin/python # coding=UTF-8 import curses import locale locale.setlocale(locale.LC_ALL,"") def doStuff(stdscr): message = u"hello ???!" stdscr.addstr(0, 0, message.encode("utf-8"), curses.A_BLINK) stdscr.getch() # pauses until a key's hit curses.wrapper(doStuff) This works. However, when I try to come up with an equivalent for Python 3.0: #!/usr/bin/python import curses import locale locale.setlocale(locale.LC_ALL,"") def doStuff(stdscr): message = "hello ???!" stdscr.addstr(0, 0, message, curses.A_BLINK) stdscr.getch() # pauses until a key's hit curses.wrapper(doStuff) It fails (printing gibberish to the console). It seems that the problem is that the curses module isn't respecting the system's preferred encoding (utf-8) which was set via the setlocale function (as per instructions at http://docs.python.org/dev/3.0/library/curses.html#module-curses). My apologies in advance if this is my mistake. Cheers! -Damian ---------- components: Unicode messages: 78563 nosy: atagar1 severity: normal status: open title: Curses Unicode Support type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:07:54 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Dec 2008 23:07:54 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230678474.37.0.200302852487.issue4787@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested your example on Linux (Ubuntu Gutsy) and it works correctly. What is your: - OS (name, version) - locale (charset?) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:11:45 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 30 Dec 2008 23:11:45 +0000 Subject: [issue4702] [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError In-Reply-To: <1229722389.12.0.525860035611.issue4702@psf.upfronthosting.co.za> Message-ID: <1230678705.41.0.391744364272.issue4702@psf.upfronthosting.co.za> Tarek Ziad? added the comment: Fixed, thanks for the patch Philip, ---------- status: open -> closed versions: +Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:11:59 2008 From: report at bugs.python.org (Damian) Date: Tue, 30 Dec 2008 23:11:59 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230678719.36.0.504289895274.issue4787@psf.upfronthosting.co.za> Damian added the comment: My OS is Ubuntu 8.04 (Hardy) and the locale is utf-8: >>> locale.setlocale(locale.LC_ALL,"") 'en_US.UTF-8' You do mean the Python 3.0 example didn't work, right? The Python3.0 header is: Python 3.0 (r30:67503, Dec 21 2008, 02:16:52) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 in case that makes a difference. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:13:46 2008 From: report at bugs.python.org (Damian) Date: Tue, 30 Dec 2008 23:13:46 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230678826.95.0.585456443864.issue4787@psf.upfronthosting.co.za> Damian added the comment: Ack - sorry, typo. I meant "You do mean the Python 3.0 example did work, right?" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:14:41 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Dec 2008 23:14:41 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230678881.11.0.58364153632.issue4787@psf.upfronthosting.co.za> STINNER Victor added the comment: > You do mean the Python 3.0 example didn't work, right? I only tested yje Python3 example and it works correctly on my computer. I'm using Python3 trunk but I don't think that the curses module changed after the 3.0 release. $ ./python Python 3.1a0 (py3k:67973M, Dec 28 2008, 17:53:52) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 >>> import locale; locale.setlocale(locale.LC_ALL, '') 'fr_FR.UTF-8' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:20:41 2008 From: report at bugs.python.org (Damian) Date: Tue, 30 Dec 2008 23:20:41 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230679241.01.0.724760551598.issue4787@psf.upfronthosting.co.za> Damian added the comment: Doing a checkout of the trunk - I'll let you know if it works. Thanks! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:28:37 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Tue, 30 Dec 2008 23:28:37 +0000 Subject: [issue4786] xml.etree.ElementTree module name in Python 3 In-Reply-To: <1230673980.62.0.10201205304.issue4786@psf.upfronthosting.co.za> Message-ID: <1230679717.28.0.118182434044.issue4786@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: ElementTree is maintained externally, that's why it wasn't renamed during the stdlib reorganization : http://www.python.org/dev/peps/pep-3108/#open-issues ---------- nosy: +quentin.gallet-gilles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:53:15 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Dec 2008 23:53:15 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230681195.7.0.517846802704.issue4787@psf.upfronthosting.co.za> STINNER Victor added the comment: I think that I catched the problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379447 _curses.so should be linked to libncursesw.so.5 and not libncurses.so.5. I tested on Hardy and I doesn't work because _curses.so was linked to libncurses.so.5. Few commands... sudo apt-get install libncursesw5-dev make clean make and it works ;-) Possible workaround: reject non-unicode ncurses library in setup.py. The ugly patch: Index: setup.py =================================================================== --- setup.py (r?vision 67973) +++ setup.py (copie de travail) @@ -848,23 +848,6 @@ panel_library = 'panelw' exts.append( Extension('_curses', ['_cursesmodule.c'], libraries = curses_libs) ) - elif (self.compiler.find_library_file(lib_dirs, 'ncurses')): - curses_libs = ['ncurses'] - exts.append( Extension('_curses', ['_cursesmodule.c'], - libraries = curses_libs) ) - elif (self.compiler.find_library_file(lib_dirs, 'curses') - and platform != 'darwin'): - # OSX has an old Berkeley curses, not good enough for - # the _curses module. - if (self.compiler.find_library_file(lib_dirs, 'terminfo')): - curses_libs = ['curses', 'terminfo'] - elif (self.compiler.find_library_file(lib_dirs, 'termcap')): - curses_libs = ['curses', 'termcap'] - else: - curses_libs = ['curses'] - - exts.append( Extension('_curses', ['_cursesmodule.c'], - libraries = curses_libs) ) else: missing.append('_curses') Ugly because it may break the curses module compilation on many OS (BSD and Solaris?). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:56:43 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Dec 2008 23:56:43 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230681403.25.0.0476598426531.issue4787@psf.upfronthosting.co.za> STINNER Victor added the comment: See also the old (and closed) issue #1428494: Prefer linking against ncursesw over ncurses library. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:01:06 2008 From: report at bugs.python.org (Damian) Date: Wed, 31 Dec 2008 00:01:06 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230681666.86.0.0339017623835.issue4787@psf.upfronthosting.co.za> Damian added the comment: Just finished recompiling and works perfectly. My hat's off to you - many thanks! -Damian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:02:11 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 31 Dec 2008 00:02:11 +0000 Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za> Message-ID: <1230681731.07.0.69777557747.issue2552@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:09:09 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:09:09 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230682149.96.0.186884700649.issue4787@psf.upfronthosting.co.za> STINNER Victor added the comment: ncursesw looks to be available for: - Linux: eg. packaged in Ubunbut - NetBSD: ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/ncursesw/README.html - FreeBSD: ncurses package with USE="unicode" - Mac OS X: http://ncursesw.darwinports.com/ - Windows: by Cygwin (libncurses5 package) I think that libncursesw is working well on Linux and BSD, but Windows port may be buggy. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:12:17 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 31 Dec 2008 00:12:17 +0000 Subject: [issue4788] two bare "except" clauses are used in the ssl module In-Reply-To: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za> Message-ID: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : >From PEP-8: > When catching exceptions, mention specific exceptions > whenever possible instead of using a bare 'except:' clause. > [...] > A bare 'except:' clause will catch SystemExit and KeyboardInterrupt > exceptions, making it harder to interrupt a program with Control-C, > and can disguise other problems. The patch in attachment removes two bare "except" clauses used in ssl module. ---------- components: Library (Lib) files: ssl.patch keywords: patch messages: 78575 nosy: giampaolo.rodola severity: normal status: open title: two bare "except" clauses are used in the ssl module versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12499/ssl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:12:24 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 31 Dec 2008 00:12:24 +0000 Subject: [issue4788] two bare "except" clauses are used in the ssl module In-Reply-To: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za> Message-ID: <1230682344.89.0.148350142702.issue4788@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : Added file: http://bugs.python.org/file12500/ssl-py3k.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:12:42 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 31 Dec 2008 00:12:42 +0000 Subject: [issue4788] two bare "except" clauses are used in the ssl module In-Reply-To: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za> Message-ID: <1230682362.58.0.310093537006.issue4788@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +janssen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:13:02 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:13:02 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230682382.04.0.328716392397.issue4787@psf.upfronthosting.co.za> STINNER Victor added the comment: For Solaris, see this bug report of nano editor: https://savannah.gnu.org/bugs/?24028 libcurses has been added to OpenSolaris in Septembre 2008. But it don't see the unicode version (libncusesw) :-/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:15:04 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:15:04 +0000 Subject: [issue4788] two bare "except" clauses are used in the ssl module In-Reply-To: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za> Message-ID: <1230682504.26.0.0895606660114.issue4788@psf.upfronthosting.co.za> STINNER Victor added the comment: socket.getpeername() can only raises an error of type socket.error, so the patch is valid and needed! ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:19:00 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:19:00 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230682740.11.0.819335316435.issue1664@psf.upfronthosting.co.za> STINNER Victor added the comment: I like nntplib_ipv6.patch: it's a generic solution (may support address families other than IPv6) and reuse code (socket.create_connection()) is always a good thing :-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:20:32 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:20:32 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230682832.05.0.559847485492.issue1664@psf.upfronthosting.co.za> STINNER Victor added the comment: About Python 2.5: this branch doesn't accept bugfix anymore, only security issues. So only Python 2.6+ and 3.0+ can be patched. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:22:02 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:22:02 +0000 Subject: [issue4777] nntplib - python 2.5 In-Reply-To: <1230617536.56.0.797389880383.issue4777@psf.upfronthosting.co.za> Message-ID: <1230682922.46.0.654687578055.issue4777@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 2.5 branch doesn't accept bugfix anymore, only security issues. See #1664 for python 2.6+ and 3.0+. ---------- nosy: +haypo resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:23:57 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:23:57 +0000 Subject: [issue4770] binascii module, crazy error messages, unexpected behavior In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za> Message-ID: <1230683037.13.0.473000127898.issue4770@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #4769 (want base64.b64decode(str)). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:29:39 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 00:29:39 +0000 Subject: [issue3023] Problem with invalidly-encoded command-line arguments (Unix) In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za> Message-ID: <1230683379.06.0.578366757243.issue3023@psf.upfronthosting.co.za> STINNER Victor added the comment: > Hmm, yes, I see that the open() builtin doesn't accept bytes > filenames, though os.open() still does. What? open() builtin, io.open() and os.open() accept bytes filename. > So what *is* os.listdir() supposed to do when it finds an > unconvertible filename? Raise an exception? os.listdir(str)->str raises an exception on undecodable filename, whereas os.listdir(bytes)->bytes doesn't write unicode error because the filename is not decoded! > What if someone puts unconvertible strings in the password database? Which database? It sounds like a different issue. It's always a good thing to reject undecodable string, even with python2 ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:37:47 2008 From: report at bugs.python.org (Mark Sapiro) Date: Wed, 31 Dec 2008 00:37:47 +0000 Subject: [issue4789] Documentation changes break existing URIs In-Reply-To: <1230683867.44.0.219209732128.issue4789@psf.upfronthosting.co.za> Message-ID: <1230683867.44.0.219209732128.issue4789@psf.upfronthosting.co.za> New submission from Mark Sapiro : The Mailman GUI contains a few links to the python.org documentation which are now broken. These links and the current equivalents are: http://www.python.org/doc/ works, but could map to http://docs.python.org/ http://www.python.org/doc/current/ works, but could map to http://docs.python.org/ http://www.python.org/doc/current/lib/ -> http://docs.python.org/library/ http://www.python.org/doc/current/lib/module-re.htm -> http://docs.python.org/library/re.html http://www.python.org/doc/current/lib/re-syntax -> http://docs.python.org/library/re.html#regular-expression-syntax http://www.python.org/doc/current/lib/typesseq-strings.html -> http://docs.python.org/library/stdtypes.html#string-formatting-operations It would be really cool if these old URIs could redirect to the new ones. ---------- assignee: georg.brandl components: Documentation messages: 78583 nosy: barry, georg.brandl, msapiro severity: normal status: open title: Documentation changes break existing URIs type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 02:07:20 2008 From: report at bugs.python.org (Nilton) Date: Wed, 31 Dec 2008 01:07:20 +0000 Subject: [issue4790] Optimization to heapq module In-Reply-To: <1230685640.21.0.309220494864.issue4790@psf.upfronthosting.co.za> Message-ID: <1230685640.21.0.309220494864.issue4790@psf.upfronthosting.co.za> New submission from Nilton : The wrapper around heapq.nlargest and heapq.nsmallest is much slower than it's C version. $ python2.5 -mtimeit -s 'import random; random.seed(123); n=999999; x=range(n); random.shuffle(x); import _heapq' '_heapq.nlargest(3, x)' 10 loops, best of 3: 142 msec per loop $ python2.5 -mtimeit -s 'import random; random.seed(123); n=999999; x=range(n); random.shuffle(x); import heapq' 'heapq.nlargest(3, x)' 10 loops, best of 3: 685 msec per loop If the key argument is None, there is no need to use the wrapper. This patch adds an a check to avoid this. ---------- components: Library (Lib) files: heapq_optimization.diff keywords: patch messages: 78584 nosy: nilton severity: normal status: open title: Optimization to heapq module versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12501/heapq_optimization.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 02:10:25 2008 From: report at bugs.python.org (Chris Morrow) Date: Wed, 31 Dec 2008 01:10:25 +0000 Subject: [issue1664] nntplib is not IPv6-capable In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za> Message-ID: <1230685825.85.0.301681883846.issue1664@psf.upfronthosting.co.za> Chris Morrow added the comment: Are we sure that the 2.6 fix (in the patch) will make it into 2.6? (and the right upstream patching will happen to the 3.0 code as well?) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 02:45:17 2008 From: report at bugs.python.org (Dan Dever) Date: Wed, 31 Dec 2008 01:45:17 +0000 Subject: [issue3023] Problem with invalidly-encoded command-line arguments (Unix) In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za> Message-ID: <1230687917.58.0.50457277161.issue3023@psf.upfronthosting.co.za> Dan Dever added the comment: >> What if someone puts unconvertible strings in the password database? > > Which database? It sounds like a different issue. It's yet another special case of the more general issue, which is that Unix strings are strings of bytes that may or may not be encoded text. Bytes of any value (save nul) are permitted in any order. There may be the occasional additional constraint: '/' is not permitted in filenames since it's the path element delimiter, for example. But you can certainly have non-text strings for file names, environment variables, command-line arguments, etc. Since Python 3 strings must be text, they cannot generally be used to represent Unix strings. David's right, "this is going to cause real problems." It has to be solved somehow, but the more obvious solutions are in some way ugly and introduce platform-to-platform inconsistencies. I occasionally skim the python-dev mailing list archive, and as far as I can tell there is yet no consensus on how to handle this. My use of Python is chiefly general-purpose scripting on Linux. Parameters to these scripts are more likely to be file names than anything else. So I can't personally consider moving to version 3 until this issue is resolved, which is why I added myself to the nosy list. I'm bothered by Martin's comment: > That os.listdir still uses bytes should be changed as well. Both > file names and command line arguments are strings, from the > viewpoint of Python. Nothing else is supported. I hope that this is nothing more than his expression of dismay that such a situation should exist, and that he doesn't mean it literally. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 02:49:03 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 31 Dec 2008 01:49:03 +0000 Subject: [issue4790] Optimization to heapq module In-Reply-To: <1230685640.21.0.309220494864.issue4790@psf.upfronthosting.co.za> Message-ID: <1230688143.73.0.374534476692.issue4790@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Am rejecting the patch because it violates the sort equivalence guarantee (including sort's promise to maintain stability). If you need the speed and don't care about sort stability, then just use _heapq.nsmallest() or _heapq.nlargest() directly. We could complexify the code a bit to achieve some automatic speed-up in the case of key==None, but my timings don't show much of an improvement: if key is None: it = izip(iterable, count()) # decorate result = _nsmallest(n, it) return map(itemgetter(0), result) # undecorate else: in1, in2 = tee(iterable) it = izip(imap(key, in1), count(), in2) # decorate result = _nsmallest(n, it) return map(itemgetter(2), result) # undecorate ---------- assignee: -> rhettinger nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 02:50:08 2008 From: report at bugs.python.org (Damian) Date: Wed, 31 Dec 2008 01:50:08 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230688208.58.0.987390627442.issue4787@psf.upfronthosting.co.za> Damian added the comment: Looks like this was my mistake, not a bug. According to: http://mail.python.org/pipermail/python-list/2007-July/450133.html Python 2.5 also requires the addition of libcursesw but it was working for the Ubuntu release because they specifically added it. There's no missing functionality - just my mistake. Cheers! -Damian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 04:43:41 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 03:43:41 +0000 Subject: [issue4788] two bare "except" clauses are used in the ssl module In-Reply-To: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za> Message-ID: <1230695021.03.0.104706915201.issue4788@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r68089 and r68091. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 05:34:03 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 31 Dec 2008 04:34:03 +0000 Subject: [issue4790] Optimization to heapq module In-Reply-To: <1230685640.21.0.309220494864.issue4790@psf.upfronthosting.co.za> Message-ID: <1230698043.19.0.481996720519.issue4790@psf.upfronthosting.co.za> Raymond Hettinger added the comment: After looking at the ugly handling of this logic in the 3.0 translation, I've reconsidered. It is better to have a separate path for the case where the key is None. See r68095 and r68096 . ---------- resolution: rejected -> accepted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 07:48:21 2008 From: report at bugs.python.org (David Morley) Date: Wed, 31 Dec 2008 06:48:21 +0000 Subject: [issue4775] Incorrect documentation - UTC time In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za> Message-ID: <1230706101.54.0.711688688948.issue4775@psf.upfronthosting.co.za> David Morley added the comment: > I propose to add this sentence to the explanation of the epoch: > > "It is platform-dependent whether or not 'seconds since the epoch' > includes leap seconds. Most systems likely implement `Unix time`_" That solution is fine. Anyone sufficiently concerned about the implications can then work out the consequences for themselves once alerted. > Please, one issue at a time. I believe that this doesn't crop up, > or if it does, it's a different issue. If you want to pursue this, > please create a separate report, and preferably include a proposed > wording. This was in response to your request for "specific other usage of UTC". The datetime module uses the term UTC very frequently but assumes a fixed 86400 second day (which is incompatible with UTC but compatible with the other Universal Times). I see this as the same issue, that is, when leap-seconds are not used it seems odd to use the more specific term "UTC" rather than the less specific "GMT" or "UT" - "UTC" is a more precise but in this case less accurate term. ...but I am happy to drop this if you don't consider it a problem. > Why do you think UT1 plays any role here? To me, but maybe not to anyone else :-), property (1a) eliminates the usefulness of the numerical representation of time for interpretation (1) of the time routines. Of the non-UTC versions of Universal Time why did I assume UT1 specifically? UT1 is the main Universal Time - the one that UTC attempts to approximate. > Computers *have* to use > SI seconds, since they are not physically equipped to measure > anything else (unless you want to get even more nit-picking and point > out that the quartz in the computer is not capable of measuring > SI seconds exactly). Well, the different Universal Times *are* nit-picking over defining seconds :-) Without the nit-picking, we would have GMT. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 08:41:56 2008 From: report at bugs.python.org (Cournapeau David) Date: Wed, 31 Dec 2008 07:41:56 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230709316.75.0.480322677508.issue2121@psf.upfronthosting.co.za> Cournapeau David added the comment: I started a patch against the trunk to handle nan/inf/infinite (I have not yet tackled the problem of negative zero). The patch is a bit big, because I found the function quite difficult to follow, so I refactored it a bit first (replacing the state machine with the big switch with a sequential parsing). One potential problem is that I do some computation with inf to make signed infinite, I don't know if it is safe. I don't know is setting a variable to Nan is safe either. Although I tested the function in a simple main under valgrind for various legit and bogus input, there is no tests in this patch. I would like to add some, but I am not familiar with python testing, so I would be glad to receive some indications on how to do it properly. ---------- keywords: +patch nosy: +cdavid Added file: http://bugs.python.org/file12502/nan_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 08:53:19 2008 From: report at bugs.python.org (Cournapeau David) Date: Wed, 31 Dec 2008 07:53:19 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230709999.46.0.208299516022.issue2121@psf.upfronthosting.co.za> Cournapeau David added the comment: Of course, I notice two bugs just after sending the patch... New patch to fix those two issues (no check for closing bracket if opening ones are there and a bug when only imaginary part is given). Added file: http://bugs.python.org/file12503/nan_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:05:27 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 31 Dec 2008 09:05:27 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230714327.11.0.619397764124.issue2121@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -1 on this feature request. IMO, it adds no value to any real world applications and isn't worth the added code complexity, the on-going maintenance burden, and the risk of introducing new bugs. ---------- nosy: +rhettinger type: -> feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:14:02 2008 From: report at bugs.python.org (Cournapeau David) Date: Wed, 31 Dec 2008 09:14:02 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230714842.91.0.101150397094.issue2121@psf.upfronthosting.co.za> Cournapeau David added the comment: I disagree the feature is not needed, for several reasons: - complex(repr(..)) roundtrip should work, whatever the value of complex is - it is supported for float, so why not for complex ? - I believe on the contrary it solves a very real problem: incidently, I got interested in this patch while working on numpy, and it is certainly useful to be able to parse nan and inf (for example when we create arrays from strings). Nan may be seen as non useful for so called real usage of python, but for scientific people, it is a crucial to have proper support of nan (which may mean missing data depending on the context) and inf. - it does not add complexity: I would argue that independantly of nan/inf support, my patch makes the function simpler to follow (no state machine with done/sw_error/etc... state). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 11:05:17 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 31 Dec 2008 10:05:17 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230717917.37.0.682360169504.issue2121@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > complex(repr(..)) roundtrip should work, Nice-to-have but not a requirement that the entire input domain be supported. > it is supported for float, so why not for complex ? It made sense for floats because of prevalence of use cases and because we wanted to match IEEE-754R as much as possible. Unfortunately, the support for Infs and NaNs has already negatively impacted the float world by making the math module harder to maintain and test. I would not like to see that extended to cmath or complex() unless compelling real-world use cases arise. > ... for scientific people, it is a crucial to have proper support > of nan (which may mean missing data depending on the context) and inf. Mark, does Inf have a standard interpretation for complex numbers? Do all infinities meet or do they radiate, each with their own phase angle? Also, do you want to stick with the 754 interpretation of NaNs as the result of invalid operations or are you comfortable with the MatLab/Octave notion of using NaNs to indicate missing values (something they do as an optimization because it is the only way to flag a non-numeric value in a floating point register or C double)? > it does not add complexity: That depends on whether handling of NaNs and Infs creeps into cmath. Mainly, I'm just questioning whether there exist compelling use cases for parsing NaNs and Infs in the context of complex numbers. ---------- assignee: -> marketdickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 11:38:26 2008 From: report at bugs.python.org (Cournapeau David) Date: Wed, 31 Dec 2008 10:38:26 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230719906.11.0.220383592414.issue2121@psf.upfronthosting.co.za> Cournapeau David added the comment: > Nice-to-have but not a requirement that the entire input domain be > supported. Ok. > It made sense for floats because of prevalence of use cases and > because we wanted to match IEEE-754R as much as possible. But why shouldn't this apply to complex numbers ? I am biased because I mainly use python for scientific work, but complex numbers are not more special than float in my mind. > Unfortunately, the support for Infs and NaNs has already negatively > impacted the float world by making the math module harder to maintain > and test. Yes, it is difficult to handle nan and inf, there are a lot of corner cases. But I fail to see how this applies here: my patch is essentially a rewrote of the parsing, and the code to handle nan/inf is only 7 lines. This is independent of the handling of how nan/inf is handled by math operations on it. > Mark, does Inf have a standard interpretation for complex numbers? > Do all infinities meet or do they radiate, each with their own phase > angle? Hm, not sure what you mean here by standard interpretation, but infinities "do not meet", in the sense that (x,inf) and (inf,x) for example can never been 'near' from each other (in the distance sense), except if x is inf. It does not make more sense to talk about phase of complex numbers with inf than for 0. But again, I don't see how this is relevant to the proposed feature. > Mainly, I'm just questioning whether there exist compelling use cases > for parsing NaNs and Infs in the context of complex numbers. For any task where parsing complex makes sense. Since many numerical operations may end up with nan or inf, this is relatively common I would say. It this can make the review easier, I can split the patch in two: first the refactoring (+ tests once someone tells me how to), and then inf/nan handling (with additional tests). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 12:34:57 2008 From: report at bugs.python.org (Cournapeau David) Date: Wed, 31 Dec 2008 11:34:57 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230723297.34.0.283665049481.issue2121@psf.upfronthosting.co.za> Cournapeau David added the comment: Ok, I found out how to make tests, and I found some problems while using this on numpy. A third version of the patch, with unit tests: all tests in test_complex.py pass. Added file: http://bugs.python.org/file12504/nan_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 12:35:08 2008 From: report at bugs.python.org (Cournapeau David) Date: Wed, 31 Dec 2008 11:35:08 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230723308.22.0.620299410817.issue2121@psf.upfronthosting.co.za> Changes by Cournapeau David : Removed file: http://bugs.python.org/file12503/nan_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 12:35:12 2008 From: report at bugs.python.org (Cournapeau David) Date: Wed, 31 Dec 2008 11:35:12 +0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1230723312.13.0.207365442001.issue2121@psf.upfronthosting.co.za> Changes by Cournapeau David : Removed file: http://bugs.python.org/file12502/nan_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 13:12:52 2008 From: report at bugs.python.org (=?utf-8?q?Sever_B=C4=83ne=C8=99iu?=) Date: Wed, 31 Dec 2008 12:12:52 +0000 Subject: [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za> Message-ID: <1230725572.69.0.11100419582.issue4263@psf.upfronthosting.co.za> Sever B?ne?iu added the comment: Thanks for the new implementation of MockNonBlockWriterIO class. It makes tests so much easier to read. There are some minor things in your patch that I would change. For example: # 1 byte will be written, the rest will be buffered raw.block_on(b"k") self.assertEquals(bufio.write(b"jklmn"), 5) # ... raw.block_on(b"0") The comment is misleading because in fact no byte is written at raw level. That's because the data size is smaller than the buffer size and the buffer is empty (was emptied by the last write call). All this renders raw.block_on(b"k") call useless. I also think this is the correct behavior regardless of implementation language of BufferedWriter class i.e. no write call should write at raw level smaller chunks of data than buffer's size unless it has to. Your tests can't cover the pre-flush condition because max_buffer_size equals buffer_size. Unless you'll beat me to it or prove me wrong, I'll update your patch next year. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 13:44:51 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 12:44:51 +0000 Subject: [issue4787] Curses Unicode Support In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za> Message-ID: <1230727491.41.0.294363842898.issue4787@psf.upfronthosting.co.za> STINNER Victor added the comment: > Python 2.5 also requires the addition of libcursesw > but it was working for the Ubuntu release because > they specifically added it. What do you mean by "the addition of libcursesw"? _curses.so of Python 2.5 is linked to libncursesw.so on Ubuntu Gutsy and Hardy. If _curses.so is linked to libncurses.so, you can not used multibyte charset like UTF-8. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 13:47:08 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 12:47:08 +0000 Subject: [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1230725572.69.0.11100419582.issue4263@psf.upfronthosting.co.za> Message-ID: <1230727598.10858.6.camel@localhost> Antoine Pitrou added the comment: > The comment is misleading because in fact no byte is written at raw > level. That's because the data size is smaller than the buffer size and > the buffer is empty (was emptied by the last write call). It depends on the implementation. A different implementation may use a different algorithm. > I also think this is the > correct behavior regardless of implementation language of BufferedWriter > class i.e. no write call should write at raw level smaller chunks of > data than buffer's size unless it has to. But how do you decide when it "has to"? Unless you want to constrain the exact implemented algorithm, you can't do that in your tests. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 13:48:14 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 31 Dec 2008 12:48:14 +0000 Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230727694.71.0.246756839749.issue4472@psf.upfronthosting.co.za> Skip Montanaro added the comment: The patch seemed to work for me. Should I worry that I don't see -fPIC or -fpic in the compile commands? Also, running "make test" before at least installing libpython2.7.dylib appears to be impossible: % otool -L python.exe python.exe: /Users/skip/local/lib/libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) regular% ./python.exe dyld: Library not loaded: /Users/skip/local/lib/libpython2.7.dylib Referenced from: /Users/skip/src/python/trunk/regular/./python.exe Reason: image not found Trace/BPT trap Is there a way to work around that? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 14:01:01 2008 From: report at bugs.python.org (Christopher Mahan) Date: Wed, 31 Dec 2008 13:01:01 +0000 Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in ftplib In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> Message-ID: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> New submission from Christopher Mahan : The python program crashes (stops responding) both from the command line and in IDLE (ver 3.0), after listing all the files in the approprate directory, both with ftp.dir() and with ftp.retrlines('LIST') (see prog listing below). I have to close the window (both window shell and IDLE). No other key combo responds. Python env (from IDLE): Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)] on win32 Program: import ftplib ftp = ftplib.FTP('ftp.edgecastcdn.net', user='theusername', passwd='thepassword') ftp.cwd('chrismahan-675') ftp.dir() #ftp.retrlines('LIST') ftp.close() The username and password are correct. I am able to use the ftp resource with filezilla (3.1.6) with no problem. This runs on a Windows Server 2003 Standard Edition, Service Pack 2. This is also a completely clean install of Python 3.0. I installed it, then wrote this program. Python 2.5 is installed on this server and runs fine. Any questions: chris.mahan at gmail.com ---------- components: Extension Modules messages: 78603 nosy: chris.mahan severity: normal status: open title: retrlines('LIST') and dir hang at end of listing in ftplib type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 14:01:59 2008 From: report at bugs.python.org (Christopher Mahan) Date: Wed, 31 Dec 2008 13:01:59 +0000 Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> Message-ID: <1230728519.48.0.355103391659.issue4791@psf.upfronthosting.co.za> Changes by Christopher Mahan : ---------- title: retrlines('LIST') and dir hang at end of listing in ftplib -> retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 14:12:18 2008 From: report at bugs.python.org (Christopher Mahan) Date: Wed, 31 Dec 2008 13:12:18 +0000 Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> Message-ID: <1230729138.48.0.664671682385.issue4791@psf.upfronthosting.co.za> Christopher Mahan added the comment: Update: Ran the same code with python 2.6.1 on the same computer, and that worked fine. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 14:47:29 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 13:47:29 +0000 Subject: [issue4539] askdirectory() in tkinter.filedialog is broken In-Reply-To: <1228431916.65.0.748760497567.issue4539@psf.upfronthosting.co.za> Message-ID: <1230731249.35.0.831561806128.issue4539@psf.upfronthosting.co.za> Guilherme Polo added the comment: I was about to mark this as invalid when I found out I had patched tkinter/filedialog.py myself. Nevertheless, this is a duplicate of issue4406 ---------- nosy: +gpolo resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 14:49:04 2008 From: report at bugs.python.org (=?utf-8?q?Sever_B=C4=83ne=C8=99iu?=) Date: Wed, 31 Dec 2008 13:49:04 +0000 Subject: [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za> Message-ID: <1230731344.27.0.696957951453.issue4263@psf.upfronthosting.co.za> Sever B?ne?iu added the comment: >> The comment is misleading because in fact no byte is written at raw >> level. That's because the data size is smaller than the buffer size and >> the buffer is empty (was emptied by the last write call). > It depends on the implementation. A different implementation may use a > different algorithm. I feel that no matter what implementation algorithm BufferedWriter uses it shouldn't write smaller chunks of data than buffer's size or else the buffer is useless. >> I also think this is the >> correct behavior regardless of implementation language of BufferedWriter >> class i.e. no write call should write at raw level smaller chunks of >> data than buffer's size unless it has to. > But how do you decide when it "has to"? Unless you want to constrain the > exact implemented algorithm, you can't do that in your tests. When a direct or indirect (e.g. on close) flush is called for the file object. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 14:49:13 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 13:49:13 +0000 Subject: [issue4406] In Lib\tkinter\filedialog.py, class Directory define loss a"_" In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za> Message-ID: <1230731353.9.0.65060679934.issue4406@psf.upfronthosting.co.za> Guilherme Polo added the comment: I'm moving this to release blocker since it went unnoticed in the 3.0 release. ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:00:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 14:00:18 +0000 Subject: [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1230731344.27.0.696957951453.issue4263@psf.upfronthosting.co.za> Message-ID: <1230732021.10858.14.camel@localhost> Antoine Pitrou added the comment: > I feel that no matter what implementation algorithm BufferedWriter uses > it shouldn't write smaller chunks of data than buffer's size or else the > buffer is useless. If you rewrite the above sentence using the word "statistically", then I can agree :) But if I look at e.g. the fwrite() manpage, I see no guarantee that the stdio layer will never make a call to write() with a size smaller than the buffer size. The buffered layer should be free to manage its buffer in what it believes is the most efficient way. The only guarantee is that it won't buffer more than max_buffer_size. Anyway :) Practically, the test does work on both py3k and another implementation, so I don't see any urgency to remove anything from it. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:27:52 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 31 Dec 2008 14:27:52 +0000 Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X? In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local> Message-ID: <1230733672.94.0.438857558984.issue4472@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Skip: * GCC always generates position-independent code on OSX * I'll look in the test issue, that's probably caused by a broken definition for RUNSHARED. Roumen: * The SHLIB_EXT definition in pyconfig.h is an issue. And I have to agree that "SO" is meant to be the suffix for python extension, given the comment about LDSHARED in configure.in (just below the definition of SHLIB_EXT). I'll work on a different way to deal with the .dylib vs. .so problem. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:45:19 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 14:45:19 +0000 Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za> Message-ID: <1230734719.35.0.458132282395.issue4749@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> vsajip nosy: +vsajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:51:33 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 14:51:33 +0000 Subject: [issue4406] In Lib\tkinter\filedialog.py, class Directory define loss a"_" In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za> Message-ID: <1230735093.41.0.992184507458.issue4406@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Fixed in r68103. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:56:03 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 14:56:03 +0000 Subject: [issue4786] xml.etree.ElementTree module name in Python 3 In-Reply-To: <1230673980.62.0.10201205304.issue4786@psf.upfronthosting.co.za> Message-ID: <1230735363.04.0.0573938673549.issue4786@psf.upfronthosting.co.za> Benjamin Peterson added the comment: So let's close this as "won't fix". ---------- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:15:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 15:15:18 +0000 Subject: [issue4718] wsgiref package totally broken In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za> Message-ID: <1230736518.47.0.762299397415.issue4718@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Philip, Graham, do you have any objections to the current patch? Otherwise I think I'm gonna commit it soon. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:29:58 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 15:29:58 +0000 Subject: [issue4792] PythonCmd in Modules/_tkinter.c should use the given "interp" parameter In-Reply-To: <1230737398.34.0.470687906349.issue4792@psf.upfronthosting.co.za> Message-ID: <1230737398.34.0.470687906349.issue4792@psf.upfronthosting.co.za> New submission from Guilherme Polo : Right now PythonCmd is using the Tcl interpreter stored in self->interp, but this is unsafe and since it is a Tcl_CmdProc it already receives the Tcl interpreter as a parameter. Using the interpreter in self->interp is unsafe because Python might deallocate this TkappObject and then PythonCmd could be invoked later, and using the interpreter given to the Tcl_CmdProc is guaranteed to be safe by Tcl. To reproduce this I needed a debug build and also needed to run the example below in the interpreter: >>> import tkFileDialog >>> tkFileDialog.askdirectory() # here I both windows, then: >>> Segmentation fault There are other ways to reproduce this but I can't remember them offhand, I know there are other ways because I've hit this same problem in another python <-> tcl bridge by doing something else. The patch could be expanded to remove the use of "self" in PythonCmd_Clientdata, but given another wish I have -- to move to Tcl_CreateObjCommand -- self would be needed again. ---------- components: Tkinter files: use_given_interp.diff keywords: patch messages: 78613 nosy: gpolo severity: normal status: open title: PythonCmd in Modules/_tkinter.c should use the given "interp" parameter versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12505/use_given_interp.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:32:21 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 31 Dec 2008 15:32:21 +0000 Subject: [issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path In-Reply-To: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za> Message-ID: <1230737541.69.0.666670439587.issue4747@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This also happens if there is any kind of syntax error in the file: "SyntaxError: None" is printed without any other hint. The (char*) filename passed to PyRun_AnyFile should be utf-8 encoded; Otherwise the file cannot be re-opened. Attached patch fixes both issues, please review. It removes one occurrence of wcstombs in favor of the PyUnicode machinery. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc stage: -> patch review Added file: http://bugs.python.org/file12506/unicode_scriptname.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:45:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 31 Dec 2008 15:45:19 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230738319.27.0.0309200670162.issue4753@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:51:02 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 31 Dec 2008 15:51:02 +0000 Subject: [issue4772] undesired switch fall-through in socketmodule.c In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za> Message-ID: <1230738662.82.0.994337210236.issue4772@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: See attached patch. ---------- keywords: +needs review, patch nosy: +amaury.forgeotdarc stage: -> patch review versions: +Python 2.6, Python 3.0 Added file: http://bugs.python.org/file12507/bluetooth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:02:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 31 Dec 2008 16:02:05 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230739325.18.0.0588390159547.issue4753@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm having trouble understanding the technique of the jump table. Can you provide some links to papers that explain the threaded code? I'm interested in learning more. How does your implementation compare to the GForth based threaded code speedwise? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:03:39 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 16:03:39 +0000 Subject: [issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path In-Reply-To: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za> Message-ID: <1230739419.74.0.3255474215.issue4747@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm unable to reproduce the problem on Linux. I wrote a script /home/haypo/???/???.py: --------------- #!/home/haypo/prog/SVN/py3k/python # -*- coding: ascii -*- print("a") --------------- The script runs fine: $ ./???.py a $ /home/haypo/prog/SVN/py3k/python ???.py a Is the problem specific to Windows? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:06:07 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 31 Dec 2008 16:06:07 +0000 Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> Message-ID: <1230739567.09.0.639092486407.issue4791@psf.upfronthosting.co.za> STINNER Victor added the comment: Can you paste the expected result of ftp.retrlines('LIST')? Does a directory contains a non-ASCII character? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:08:59 2008 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 31 Dec 2008 16:08:59 +0000 Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za> Message-ID: <1230739739.95.0.429582932791.issue4749@psf.upfronthosting.co.za> Vinay Sajip added the comment: Can you (Mohammad) say which specific tickets raised the same issue? I downloaded and ran your script (Windows XP Pro, ActivePython 2.5.2.2) and had no problems. I created a .bat file with 100 invocations of the .py file. Lowell Alleman refers to concurrent use of a single log file by multiple processes - this is not supported as there is no cross-platform method of handling multiple process contention for a file. Lowell's handler uses a portalocker module which is for NT or posix only - if this works for you, then great. The preferred way of dealing with logging to a single file from multiple processes is to use a SocketHandler from the processes, and a separate socket receiver application which receives the events and logs to file. An example is in the docs: http://docs.python.org/library/logging.html#sending-and-receiving-logging-events-across-a-network I'll change the status of this issue to Pending while I wait for info on other tickets about this - but multiple process support for any logging to file (whether rotating or not) is not supported and won't be until there is a cross-platform mechanism for file locking in the stdlib. N.B. re your script - logging.shutdown() need not be called by your script, as logging registers an atexit handler to do this automatically. ---------- resolution: -> works for me status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:15:22 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 16:15:22 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230739325.18.0.0588390159547.issue4753@psf.upfronthosting.co.za> Message-ID: <1230740121.10858.30.camel@localhost> Antoine Pitrou added the comment: > I'm having trouble understanding the technique of the jump table. Can > you provide some links to papers that explain the threaded code? I'm > interested in learning more. I haven't read any papers. Having a jump table in itself isn't special (the compiler does exactly that when compiling the switch() statement). What's special is that a dedicated indirect jump instruction at the end of each opcode helps the CPU make a separate prediction for which opcode follows the other one, which is not possible with a switch statement where the jump instruction is shared by all opcodes. I believe that's where most of the speedup comes from. If you read the patch it will probably be easy to understand. I had the idea to try this after a thread on pypy-dev, there are more references there: http://codespeak.net/pipermail/pypy-dev/2008q4/004916.html > How does your implementation compare to the GForth based threaded code > speedwise? Don't know! Your experiments are welcome. My patch is far simpler to integrate though (it's small, introduces very few changes and does not break any existing tests). _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:46 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 31 Dec 2008 16:21:46 +0000 Subject: [issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path In-Reply-To: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za> Message-ID: <1230740506.69.0.159594986294.issue4747@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes. As usual, the problem occurs when the platform encoding (used by wcstombs) is not utf-8. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:24:19 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 16:24:19 +0000 Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za> Message-ID: <1230740659.35.0.0451634761813.issue3638@psf.upfronthosting.co.za> Antoine Pitrou added the comment: "tkinter.mainloop" seems used in a bunch of places according to Google Code. Am I missing something? http://www.google.com/codesearch?hl=fr&lr=&q=%22tkinter.mainloop%22&sbtn=Rechercher ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:24:20 2008 From: report at bugs.python.org (Andrew) Date: Wed, 31 Dec 2008 16:24:20 +0000 Subject: [issue4732] Object allocation stress leads to segfault on RHEL In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> Message-ID: <1230740660.45.0.735373852803.issue4732@psf.upfronthosting.co.za> Andrew added the comment: This problem appears to be specific to RHEL 5, and is not a Python problem. Linking against Google malloc (libtcmalloc) fixes the issue. This bug should be closed. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:13 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 16:25:13 +0000 Subject: [issue4732] Object allocation stress leads to segfault on RHEL In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za> Message-ID: <1230740713.25.0.325137189532.issue4732@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, thanks for the investigation! ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:27:31 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 16:27:31 +0000 Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it In-Reply-To: <1230740659.35.0.0451634761813.issue3638@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: On Wed, Dec 31, 2008 at 2:24 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > "tkinter.mainloop" seems used in a bunch of places according to Google > Code. Am I missing something? > Yes, those are not _tkinter.mainlooop, they are Tkinter.mainloop. > http://www.google.com/codesearch?hl=fr&lr=&q=%22tkinter.mainloop%22&sbtn=Rechercher > _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:30:11 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 16:30:11 +0000 Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it In-Reply-To: Message-ID: Guilherme Polo added the comment: On Wed, Dec 31, 2008 at 2:27 PM, Guilherme Polo wrote: > > Guilherme Polo added the comment: > > On Wed, Dec 31, 2008 at 2:24 PM, Antoine Pitrou wrote: >> >> Antoine Pitrou added the comment: >> >> "tkinter.mainloop" seems used in a bunch of places according to Google >> Code. Am I missing something? >> > > Yes, those are not _tkinter.mainlooop, they are Tkinter.mainloop. > Or were you referring to my other comment about removing it from Tkinter.py too ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:30:57 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 16:30:57 +0000 Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it In-Reply-To: Message-ID: <1230741061.10858.31.camel@localhost> Antoine Pitrou added the comment: Well, well, sorry for the noise! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:37:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 31 Dec 2008 16:37:27 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230740121.10858.30.camel@localhost> Message-ID: <495B9FC1.90803@cheimes.de> Christian Heimes added the comment: > I haven't read any papers. Having a jump table in itself isn't special > (the compiler does exactly that when compiling the switch() statement). > What's special is that a dedicated indirect jump instruction at the end > of each opcode helps the CPU make a separate prediction for which opcode > follows the other one, which is not possible with a switch statement > where the jump instruction is shared by all opcodes. I believe that's > where most of the speedup comes from. > > If you read the patch it will probably be easy to understand. You are right. It's easier to understand after I've learned how the opcode_targets table is working. Previously I didn't know that one can store the address of a label in an array. Before I got it I wondered where the pointers were defined. Is this a special GCC feature? I haven't seen it before. > Don't know! Your experiments are welcome. My patch is far simpler to > integrate though (it's small, introduces very few changes and does not > break any existing tests). Yes, your patch is much smaller, less intrusive and easier to understand with a little background in CS. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:40:49 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 16:40:49 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <495B9FC1.90803@cheimes.de> Message-ID: <1230741654.10858.33.camel@localhost> Antoine Pitrou added the comment: > Is this a special GCC feature? Yes, it is. http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:43:11 2008 From: report at bugs.python.org (Christopher Mahan) Date: Wed, 31 Dec 2008 16:43:11 +0000 Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> Message-ID: <1230741791.27.0.154994336617.issue4791@psf.upfronthosting.co.za> Christopher Mahan added the comment: the output: just before the non-responsiveness: -rwxrwxrwx 1 nobody nogroup 3905538 Dec 29 09:51 Bronski Beat - Why.mp3 -rwxrwxrwx 1 nobody nogroup 873966 Dec 28 13:53 test9.avi -rwxrwxrwx 1 nobody nogroup 2512653 Dec 29 08:28 test9_lg.wmv -rwxrwxrwx 1 nobody nogroup 6549 Dec 29 08:28 test9_lg.wmv.jpg -rwxrwxrwx 1 nobody nogroup 1788466 Dec 29 03:04 test9_med.flv -rwxrwxrwx 1 nobody nogroup 6394 Dec 29 03:04 test9_med.flv.jpg -rwxrwxrwx 1 nobody nogroup 1263041 Dec 28 13:53 test9_sm.flv -rwxrwxrwx 1 nobody nogroup 6465 Dec 28 13:53 test9_sm.flv.jpg Added file: http://bugs.python.org/file12508/from_filezilla.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:44:21 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 31 Dec 2008 16:44:21 +0000 Subject: [issue4670] setup.py exception when db_setup_debug = True In-Reply-To: <1229341792.75.0.0111494669008.issue4670@psf.upfronthosting.co.za> Message-ID: <1230741861.31.0.918495705676.issue4670@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Closing as "out of date": 2.6.0 already has the fix (since r54124), and 2.5 is now in security-fixes-only mode. ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:46:31 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Wed, 31 Dec 2008 16:46:31 +0000 Subject: [issue4508] distutils compiler not handling spaces in path to output/src files In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za> Message-ID: <1230741991.08.0.114621467463.issue4508@psf.upfronthosting.co.za> Tarek Ziad? added the comment: Hi. I am not familiar with weave. Could you provide a small sample of code that raises this issue. This way, I will be able to write the standalone test we can integrate in distutils together with your fix. ---------- assignee: -> tarek nosy: +tarek priority: -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:48:08 2008 From: report at bugs.python.org (Christopher Mahan) Date: Wed, 31 Dec 2008 16:48:08 +0000 Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> Message-ID: <1230742088.58.0.563011533692.issue4791@psf.upfronthosting.co.za> Christopher Mahan added the comment: Added file screenshot of filezilla view of the folder in question. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:04:35 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 17:04:35 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: <1230743075.69.0.250710310194.issue734176@psf.upfronthosting.co.za> Guilherme Polo added the comment: Eh.. old. Anyway, I have made a patch against trunk now and it should work with any nested level of cloned menus according to how tk names cloned menus. ---------- nosy: +gpolo versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.3 Added file: http://bugs.python.org/file12509/nametowidget_clonedmenus.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:07:24 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Wed, 31 Dec 2008 17:07:24 +0000 Subject: [issue1702551] distutils sdist does not exclude SVN/CVS files on Windows Message-ID: <1230743244.64.0.998257194531.issue1702551@psf.upfronthosting.co.za> Tarek Ziad? added the comment: I have put this ticket in my pile. I will write the test to demonstrate the problem and get back to your patch proposal. As Christian said, both separator should be taken care of under Windows, so the final regexp will be slighly different. Last, the trunk code has evolved a bit since your initial proposal, and now includes other VCSs like Mercurial or Git. ---------- assignee: -> tarek nosy: +tarek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:09:52 2008 From: report at bugs.python.org (Christopher Mahan) Date: Wed, 31 Dec 2008 17:09:52 +0000 Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za> Message-ID: <1230743392.05.0.856406791058.issue4791@psf.upfronthosting.co.za> Christopher Mahan added the comment: The list does not seem to contain non-ascii characters. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:24:34 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 17:24:34 +0000 Subject: [issue995925] method after() and afer_idle() are not thread save Message-ID: <1230744274.06.0.913532658064.issue995925@psf.upfronthosting.co.za> Guilherme Polo added the comment: This is not going to happen. You should be protecting it yourself since this is a special case. ---------- nosy: +gpolo resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:26:47 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 31 Dec 2008 17:26:47 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230744407.82.0.661920407591.issue4753@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:39:31 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 17:39:31 +0000 Subject: [issue2693] IDLE doesn't work with Tk 8.5 In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za> Message-ID: <1230745171.71.0.662012612079.issue2693@psf.upfronthosting.co.za> Guilherme Polo added the comment: Closing as only r59654 was backported to release25-maint, so Tk 8.5 is not fully supported by the standard Tkinter present in python 2.5.x ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:39:46 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 17:39:46 +0000 Subject: [issue2693] IDLE doesn't work with Tk 8.5 under python 2.5 and older In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za> Message-ID: <1230745186.45.0.861353533794.issue2693@psf.upfronthosting.co.za> Changes by Guilherme Polo : ---------- title: IDLE doesn't work with Tk 8.5 -> IDLE doesn't work with Tk 8.5 under python 2.5 and older _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:42:15 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 17:42:15 +0000 Subject: [issue2995] Idle, some Linuxes, cannot position Cursor by mouseclick In-Reply-To: <1211995180.72.0.174580651078.issue2995@psf.upfronthosting.co.za> Message-ID: <1230745335.62.0.0236147092001.issue2995@psf.upfronthosting.co.za> Guilherme Polo added the comment: Can you retry making some small example that demonstrates the problem ? ---------- nosy: +gpolo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:45:25 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 17:45:25 +0000 Subject: [issue2638] tkSimpleDialog Window Flashing In-Reply-To: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za> Message-ID: <1230745525.36.0.435871754218.issue2638@psf.upfronthosting.co.za> Guilherme Polo added the comment: Dropped for inclusion in python 2.5, but should still be considered for trunk and py3k. ---------- resolution: -> accepted versions: +Python 2.7, Python 3.0, Python 3.1 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:56:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 17:56:11 +0000 Subject: [issue2734] 2to3 converts long(itude) argument to int In-Reply-To: <1209669660.53.0.857681626906.issue2734@psf.upfronthosting.co.za> Message-ID: <1230746171.0.0.742422548409.issue2734@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I hope r68106 helps. 2to3 now refuses to change long if it is being assigned to, the name of a function or class, the name of an argument, or an attribute. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:22:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 18:22:52 +0000 Subject: [issue3260] fix_imports does not handle intra-package renames In-Reply-To: <1215028935.08.0.401449015598.issue3260@psf.upfronthosting.co.za> Message-ID: <1230747772.37.0.732955423394.issue3260@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think I will close this as "won't fix". As you say, the only applicable rename is test.test_support. That only is not enough IMO to add all the complexity to fix_imports that handling packages properly would require. ---------- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:59:36 2008 From: report at bugs.python.org (Lenard Lindstrom) Date: Wed, 31 Dec 2008 18:59:36 +0000 Subject: [issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar" In-Reply-To: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za> Message-ID: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za> New submission from Lenard Lindstrom : http://www.python.org/doc/2.6/glossary.html The decorator entry in the Python 2.6 documentation incorrectly describes a decorator as "merely syntactic sugar". It is not, as this example shows: >>> def decorator(f): f.prev = globals()[f.__name__] return f >>> func = 0 >>> def func(): pass >>> func = decorator(func) >>> func.prev >>> func = 0 >>> @decorator def func(): pass >>> func.prev 0 This distinction could be useful in building multi-methods, for example. ---------- assignee: georg.brandl components: Documentation messages: 78643 nosy: georg.brandl, kermode severity: normal status: open title: Glossary incorrectly describes a decorator as "merely syntactic sugar" versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:22:09 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 31 Dec 2008 19:22:09 +0000 Subject: [issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar" In-Reply-To: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za> Message-ID: <1230751329.41.0.186775268223.issue4793@psf.upfronthosting.co.za> Guilherme Polo added the comment: Your example doesn't disprove the "merely syntactic sugar" found in the documentation about the decorator syntax. The results you are getting are based on when the decorator is applied. ---------- nosy: +gpolo resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:31:45 2008 From: report at bugs.python.org (Pavel Kosina) Date: Wed, 31 Dec 2008 19:31:45 +0000 Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8 In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za> Message-ID: <1230751905.3.0.745179158847.issue2827@psf.upfronthosting.co.za> Pavel Kosina added the comment: the following very simple example might be the the same issue: x="?????????" print (x) It reliably puts down IDLE entirely without any error message. It is saved in UTF-8. python +idle 3.0, wxp sp3 ---------- nosy: +geon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:34:46 2008 From: report at bugs.python.org (darrenr) Date: Wed, 31 Dec 2008 19:34:46 +0000 Subject: [issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za> Message-ID: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za> New submission from darrenr : Python's garbage collector holds GIL during collection and doesn't provide any method of interruption or concurrency with other Python threads within a single Python VM. This can be a problem for realtime applications. The worst-case performance of the garbage collector takes linear time with respect to the number of Python objects that could potentially be involved in a garbage cycle. I've attached timings taken on a Core 2 Quad 2.4 GHz (WinXP Pro, 3GB RAM), with ever-increasing numbers of objects. The gc at worst takes upwards of 3 seconds before the process runs out of memory. If gc periodically released the GIL it would allow it to be put in a separate thread, but as it stands it blocks the Python VM for periods of time that are too long for realtime interactive applications. Alternatively a gc that is incremental by default would eliminate the need for a second thread. ---------- files: gctimings.zip messages: 78646 nosy: darrenr severity: normal status: open title: garbage collector blocks and takes worst-case linear time wrt number of objects versions: Python 2.4, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file12510/gctimings.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:35:18 2008 From: report at bugs.python.org (darrenr) Date: Wed, 31 Dec 2008 19:35:18 +0000 Subject: [issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za> Message-ID: <1230752118.52.0.656939656459.issue4794@psf.upfronthosting.co.za> Changes by darrenr : ---------- components: +Interpreter Core type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:44:27 2008 From: report at bugs.python.org (Lenard Lindstrom) Date: Wed, 31 Dec 2008 19:44:27 +0000 Subject: [issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar" In-Reply-To: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za> Message-ID: <1230752667.11.0.970740513714.issue4793@psf.upfronthosting.co.za> Lenard Lindstrom added the comment: It is distinct behavior. Without a decorator a new function is immediately assigned to the identifier. Any previous reference is lost. A decorator postpones assignment until the decorator returns. That allows the decorator to access the previous object. I don't know of any way to do the same thing with: def foo(): ..... foo = do_something(foo) Here is part of a comp.lang.python thread discussing the possibility of using a decorator for an overloaded function. http://groups.google.com/group/comp.lang.python/browse_thread/thread/16a2e8b9d6705dfb/1cb0b358173daf06?lnk=gst&q=Lenard+Lindstrom+decorator#1cb0b358173daf06 Note that the decorator could create an overloaded function without any extra variables. To do the equivalent in Python 2.3 a special attribute, with a mangled name, was needed to store intermediate declarations. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:55:16 2008 From: report at bugs.python.org (David W. Lambert) Date: Wed, 31 Dec 2008 19:55:16 +0000 Subject: [issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za> Message-ID: <1230753316.62.0.209471408445.issue4794@psf.upfronthosting.co.za> Changes by David W. Lambert : ---------- nosy: +LambertDW _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:55:44 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 19:55:44 +0000 Subject: [issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar" In-Reply-To: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za> Message-ID: <1230753344.56.0.830986132684.issue4793@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It is possible to "desugar" the exact behavior by creating the function ones self. Regardless, the usefulness this behavior is limited because it relys on the decorator being in the same module as the function. It is also fragile for nested functions. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:58:42 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 19:58:42 +0000 Subject: [issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za> Message-ID: <1230753522.91.0.0312261787802.issue4794@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The garbage collector will never be able to run in a second thread because it manipulates Python objects, which the GIL is supposed to protect! As for non-linear complexity, see #4688 and #4074 for some attempts to sooth this problem over. ---------- nosy: +benjamin.peterson resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 21:11:50 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2008 20:11:50 +0000 Subject: [issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path In-Reply-To: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za> Message-ID: <1230754310.42.0.201914928147.issue4747@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Looks good. ---------- keywords: -needs review nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 21:25:02 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 20:25:02 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230755102.52.0.521812333527.issue4753@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch adds some detailed comments, at Jason Orendorff's request. Added file: http://bugs.python.org/file12511/threadedceval3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 22:17:54 2008 From: report at bugs.python.org (Lenard Lindstrom) Date: Wed, 31 Dec 2008 21:17:54 +0000 Subject: [issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar" In-Reply-To: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za> Message-ID: <1230758274.52.0.977124764157.issue4793@psf.upfronthosting.co.za> Lenard Lindstrom added the comment: The claim "merely" syntactic sugar implies that the inverse is also true, the decorator expression: @do_something def foo(): .... can be replaced it with: def foo(): .... foo = do_something(foo) This is guaranteed if do_something is purely functional, but breaks if do_something has side effects. The example was for illustration only. A real application would likely access the parent frame. Whether or not this is a questionable practice, it happens. However, the issue is one of definitions. Is the phrase "merely syntactic sugar" misleading? In this case it makes promises that may not be kept. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 22:21:02 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Wed, 31 Dec 2008 21:21:02 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230758462.37.0.48659077371.issue4753@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: You may want to check out issue1408710 in which a similar patch was provided, but failed to deliver the desired results. I didn't get the advertised ~15% speed-up, but only 4% on my Intel Core2 laptop and 8% on my AMD Athlon64 X2 desktop. I attached the benchmark results. The patch looks pretty clean. Here is a few things that caught my attention while reading your patch. First, you should rename opcode_targets.c to opcode_targets.h. This will make it explicit that the file is not compiled, but just included. Also, the macro USE_THREADED_CODE should be renamed to something else; the word "thread" is too tightly associated with multi-threading. Furthermore, threaded code simply refers to code consisting only of function calls. Maybe, USE_COMPUTED_GOTO or USE_DIRECT_DISPATCH would be better. Finally, why do you disable your patch when DYNAMIC_EXECUTION_PROFILE or LLTRACE is enabled? I tested your patch with both enabled and I didn't see any test failures. By the way, SUNCC also supports GCC's syntax for labels as values (http://docs.sun.com/app/docs/doc/819-5265/bjabt?l=en&a=view). ---------- nosy: +alexandre.vassalotti Added file: http://bugs.python.org/file12512/amd-athlon64-x2-pybench.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 22:21:35 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Wed, 31 Dec 2008 21:21:35 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230758495.78.0.728533375847.issue4753@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Added file: http://bugs.python.org/file12513/intel-core2-mobile-pybench.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 22:28:41 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 31 Dec 2008 21:28:41 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230758921.39.0.182563505263.issue4753@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 22:48:24 2008 From: report at bugs.python.org (Nilton Volpato) Date: Wed, 31 Dec 2008 21:48:24 +0000 Subject: [issue4790] Optimization to heapq module In-Reply-To: <1230685640.21.0.309220494864.issue4790@psf.upfronthosting.co.za> Message-ID: <1230760104.39.0.704951036495.issue4790@psf.upfronthosting.co.za> Nilton Volpato added the comment: Nice! Maybe we could add the decorate/undecorate step to guarantee stability to the C implementation. I'll do some experiments and timings on this. The heapq library has a lot of room for optimization, I think. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 23:10:48 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 31 Dec 2008 22:10:48 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230761448.56.0.552488657179.issue4753@psf.upfronthosting.co.za> Skip Montanaro added the comment: Works pretty well for me on my MacBook Pro, but on my G5 it performed abysmally. In fact, it ran so much worse that I cleaned up my sandbox and did both checks all over again to make sure I didn't mess something up. It looks like my MacBook Pro saw about a 14% degradation. Both computers are running Mac OS X 10.5.6 with the latest Xcode - 3.1.2. On both computers gcc -v reports 4.0.1, Apple build 5490. If this is applied to the core I think it will have to select for more than just gcc. It will also have to select based on the chip architecture. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 23:11:49 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 31 Dec 2008 22:11:49 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230761509.16.0.162398302205.issue4753@psf.upfronthosting.co.za> Changes by Skip Montanaro : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 23:12:29 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 31 Dec 2008 22:12:29 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1230761549.36.0.776737149622.issue4753@psf.upfronthosting.co.za> Skip Montanaro added the comment: Works pretty well for me on my MacBook Pro, but on my G5 it performed abysmally. In fact, it ran so much worse that I cleaned up my sandbox and did both checks all over again to make sure I didn't mess something up. It looks like my MacBook Pro saw about a 7% improvement while my G5 saw a 14% degradation. Both computers are running Mac OS X 10.5.6 with the latest Xcode - 3.1.2. On both computers gcc -v reports 4.0.1, Apple build 5490. If this is applied to the core I think it will have to select for more than just gcc. It will also have to select based on the instruction set architecture. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 23:17:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2008 22:17:18 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230761448.56.0.552488657179.issue4753@psf.upfronthosting.co.za> Message-ID: <1230761840.18815.20.camel@localhost> Antoine Pitrou added the comment: > Works pretty well for me on my MacBook Pro, but on my G5 it performed > abysmally. In fact, it ran so much worse that I cleaned up my sandbox > and did both checks all over again to make sure I didn't mess something > up. It looks like my MacBook Pro saw about a 14% degradation. Both > computers are running Mac OS X 10.5.6 with the latest Xcode - 3.1.2. > On both computers gcc -v reports 4.0.1, Apple build 5490. You're sure you didn't compile in debug mode or something? Just checking. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 23:24:15 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 31 Dec 2008 22:24:15 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230761840.18815.20.camel@localhost> Message-ID: <18779.61708.127954.545901@montanaro-dyndns-org.local> Skip Montanaro added the comment: Antoine> You're sure you didn't compile in debug mode or something? Just Antoine> checking. There was a cut-n-paste error in that one which I noticed right after submitting (man, do I hate the crappy editing capability of