[issue3441] Regression in module as a script command-line option
Nick Coghlan [EMAIL PROTECTED] added the comment: Now, if someone was to provide a 2.7 rfe with associated patch that implements this feature properly, and includes an explanation for why it doesn't subtly break imports the way 2.5 does, that would be a completely different story. But it isn't as simple as just getting rid of the explicit check that prevents packages from being executed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3441] Regression in module as a script command-line option
Richard Jones [EMAIL PROTECTED] added the comment: I'm afraid it's all a bit opaque to an outsider like me. I've no idea what subtle breakage the feature was causing. I just saw it working quite nicely for me in 2.5 :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3441] Regression in module as a script command-line option
Nick Coghlan [EMAIL PROTECTED] added the comment: If I recall correctly (it's been a while), the breakages were tied in with relative imports - probably something like explicit relative imports not working at all, and implicit relative imports appearing to work, but resulting in incorrect module names and sys.modules entries (similar to running a file from inside a package directly). Doing python -m package.__init__ instead of python -m package is actually better behaved (although still a little odd - the __init__ module code gets run once on the actual package import, and then again as __main__). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3449] Update decimal module to version 1.68 of the IBM specification
Mark Dickinson [EMAIL PROTECTED] added the comment: Looks like the changes needed here are even more minor than I thought. The decimal module already does the right thing with respect to the new specification and the new tests. So all that needs doing is to replace the old tests with the new ones. No changes to decimal.py or test_decimal.py are necessary. Here's a patch. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3449 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3449] Update decimal module to version 1.68 of the IBM specification
Changes by Mark Dickinson [EMAIL PROTECTED]: -- keywords: +patch Added file: http://bugs.python.org/file10987/issue3449.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3449 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3421] Test failure in test_math::testSum
Mark Dickinson [EMAIL PROTECTED] added the comment: Sadly, this is not the only problem with math.sum on x86 hardware right now. I'd guess that this is another problem related to double-rounding and the use of 80-bit floating-point registers on x86. Raymond and I are still actively looking for ways to fix math.sum up, including the possibility of a complete rewrite using a totally different algorithm. With the current algorithm, behaviour at or near the boundary of the floating-point range should really be considered undefined; so the quick fix is to update the tests and docs to reflect this. The particular test that causes test.math to fail would just be removed. I am intrigued that py3k and the trunk give different results, though; I'd very much like to know where the difference comes from. Georg, *only if you have time*, could you please tell me what results the linux box gives for the following two Python sums, in both py3k and the trunk: 1e16 + 2. 10002.0 1.7976931348623157e+308 + 9.979201547673598e+291 1.7976931348623157e+308 (The results shown are the ones I get on OS X 10.5.4; I don't have access to a linux box for testing at the moment.) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3421 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3421] Test failure in test_math::testSum
Mark Dickinson [EMAIL PROTECTED] added the comment: See also issue 2819 for ongoing discussion, and issue 2937, which is the likely root cause of the current difficulties with math.sum. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3421 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2819] Full precision summation
Mark Dickinson [EMAIL PROTECTED] added the comment: Here's a patch giving an alternative implementation of math.fsum; it's based on Tim Peter's suggestions, works mostly with integer arithmetic, and so bypasses problems with double rounding and extended precision floats. The patch is experimental: it doesn't have sufficient tests, has no documentation, and it adds math.fsum alongside the current math.sum, to make it easy to compare the two implementations. On my MacBook, math.fsum is a factor of 2-3 times slower than math.sum. It's also longer and distinctly less elegant. So its only real advantage is that it should fix the difficulties on x86 hardware. We *really* need to sort math.sum out, one way or another, before the next beta. Georg recently discovered another problem on x86/Linux: see issue 3421. Some options: (1) leave math.sum as it is, skip all tests on x86/Linux, and document the current behaviour. (2) investigate a version of math.sum that plays with the FPU control word to force 53-bit rounding (and round-half-even) (3) replace math.sum with the slower but (presumably) less erratic math.fsum, possibly just as a temporary measure. This would at least get all tests passing. Jean, Raymond: what do you think? Added file: http://bugs.python.org/file10988/fsum7.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3421] Test failure in test_math::testSum
Georg Brandl [EMAIL PROTECTED] added the comment: Both trunk and 3k give this: 1e16 + 2. 10004.0 1.7976931348623157e+308 + 9.979201547673598e+291 inf ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3421 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3437] robotparser.py missing one line
Skip Montanaro [EMAIL PROTECTED] added the comment: Attached is a patch against 2.6 which adds the missing line (state = 2), a comment describing the three states the parser can be in and expands the test cases to cover this change (fail without it, pass with it). In the process I snagged some broken example robots.txt files from Google's Googlebot help pages and turned them into test cases, both before and after fixing the examples. I think this can probably go into the repository as a bug fix and get merged to the py3k branch. If nobody complains in the next day or two I'll apply it. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3450] Buy stocks now to make money
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10989/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3450] Buy stocks now to make money
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3450] Buy stocks now to make money
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3356] some tests fail with Py_DEBUG (test_distutils, test_set)
Antoine Pitrou [EMAIL PROTECTED] added the comment: Hmm, ok. I was using `make EXTRA_CFLAGS=-DPy_DEBUG`, but it wouldn't undefine NDEBUG so the assert() macro wouldn't be enabled. By using `make EXTRA_CFLAGS=-DPy_DEBUG -UNDEBUG` instead it's fine. But that makes test_c_api in setobject.c bogus, because it relies on the execution of assert() statements to modify the refcount of certain objects - which doesn't happen when assert() is optimized out. The only reason it doesn't crash in non-debug mode is that the deallocated objects are still intact in memory, and Py_REFCNT simply drops their refcount field to -1 without bothering. It also means the following statement in Misc/SpecialBuilds.txt is misleading: « Py_DEBUG implies LLTRACE, Py_REF_DEBUG, Py_TRACE_REFS, and PYMALLOC_DEBUG (if WITH_PYMALLOC is enabled). In addition, C assert()s are enabled (via the C way: by not defining NDEBUG) » I haven't looked at the distutils problem yet. -- assignee: - georg.brandl components: +Documentation -Tests nosy: +georg.brandl priority: - high title: some tests fail in debug mode (test_distutils, test_set) - some tests fail with Py_DEBUG (test_distutils, test_set) type: crash - behavior versions: +Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3356] some tests fail with Py_DEBUG (test_distutils, test_set)
Antoine Pitrou [EMAIL PROTECTED] added the comment: Py_REFCNT simply drops their refcount field to -1 without bothering. I meant Py_DECREF. -- components: +Tests type: behavior - crash ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: (1) are you sure it is safe not to INCREF the obj pointer in the Py_buffer? Yes, that's the semantics of the current buffer interface, and I cannot see a flaw in it. When you call getbuffer, you certainly hold a reference, and it is your obligation to hold onto this reference somehow. So it is definitely safe (if properly documented). It would seem more logical for PyBuffer_FillInfo to INCREF the obj, and for PyBuffer_Release to DECREF it and set it to NULL. Perhaps. I cannot quite see what undesirable consequences that might have - feel free to develop and test an alternative patch that takes that approach. (2) is it necessary to call directly bf_getbuffer the like or is there a higher-level API to do it? There is PyObject_GetBuffer and PyObject_ReleaseBuffer, but it is not higher-level. I need to check the function pointers, anyway (to determine whether the object supports getbuffer and requires releasebuffer or not), so calling them directly is the right level of abstraction (IMO). (3) didn't you forget to convert PyArg_ParseTuple(args, s#iO:sendto, [...]) in sock_sendto? True. (4) is it really necessary to do a special case with PyString_Check() rather than rely on the string type's getbuffer method? That's what the code always did (for s#). It would be possible to eliminate that case, yes. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1446] Link to call me for free
Changes by Georg Brandl [EMAIL PROTECTED]: ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1446 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3421] Test failure in test_math::testSum
Mark Dickinson [EMAIL PROTECTED] added the comment: Thanks. Those are the results I'd expect on x86. So here's the puzzle: On lines 658-9 of Lib/test/test_math.py, in revision 65248 of the py3k branch, there's a pair of lines that looks like: if 1e16+2.999 != 1e16+2.: return These lines are supposed to bail out of testSum on IEEE 754 hardware that doesn't do correct rounding. So on your machine, I'd expect: 1e16+2.999 to evaluate to 10002.0 1e16+2. to evaluate to 10004.0 so the condition in the if statement ought to be True, and the rest of the tests should be skipped. It looks like this bailout is working as intended in the trunk, but not in Py3k. Any ideas why there's a difference? Is there some sort of constant folding going on in py3k but not in the trunk? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3421 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3421] Test failure in test_math::testSum
Georg Brandl [EMAIL PROTECTED] added the comment: Strangely, it seems to work now with 3k too -- both in a debug and release build. I've no idea what changed, but I'll close this for now. -- resolution: - works for me status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3421 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1064] Test issue
Martin v. Löwis [EMAIL PROTECTED] added the comment: A new message for spambayes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3353] make built-in tokenizer available via Python C API
Andy [EMAIL PROTECTED] added the comment: Did that and it builds fine. So my test procedure was: - checkout clean source - apply patch as per guidelines - remove the file Psrser/tokenizer.h (*) - ./configure - make - ./python setup.py install Build platform: Ubuntu , gcc 4.2.3 All works fine. thanks for the extra test files. * - one question though. I removed the file using 'svn remove' but the diff makes it an empty file not removed why is that? (and is it correct?) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3421] Test failure in test_math::testSum
Raymond Hettinger [EMAIL PROTECTED] added the comment: The tests at floating point boundaries should probably be removed and their behavior should be left undefined. -- nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3421 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3437] robotparser.py missing one line
Skip Montanaro [EMAIL PROTECTED] added the comment: committed as r 65255. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3449] Update decimal module to version 1.68 of the IBM specification
Facundo Batista [EMAIL PROTECTED] added the comment: The patch looks great, feel free to apply it and commit. For the record: the name issue that Mark talked about is not in this last change, it was before, and we handled it the way we now decide (hey, at least we're coherent with ourselves, ;) ). Thank you Mark! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3449 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3451] Asymptotically faster divmod and str(long)
New submission from Fredrik Johansson [EMAIL PROTECTED]: A few weeks ago, I blogged about taking advantage of Karatsuba multiplication and Newton's method to divide big integers quickly (some of you may have read it, as it was posted to Daily Python-URL among other places): http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html To summarize, this method blows the builtin division out of the water already at ~(2000 digits)/(1000 digits). The primary catch is that the result of the Newton division may be slightly wrong (typically 1 ulp). However, a single extra multiplication and a subtraction at the end allows one to compute a remainder, and since the remainder must satisfy 0 = r q, the error is easily corrected. From a quick test, the cost of the extra multiplication seems to move the break-even point with the builtin division up to around 5000/2500 digits. A pure Python implementation of divmod, with error correction based on the remainder, can be found in this file: http://www.dd.chalmers.se/~frejohl/code/libarith/libarith.py (See the function idivmod) Of particular note is that fast divmod gives a fast way to do radix conversion, by recursively splitting the number in half. The function numeral (see same .py file) does this, e.g: from time import clock a = 2**1257787-1 t1=clock(); s1=str(a); t2=clock(); t2-t1 109.08065159119386 t1=clock(); s2=numeral(a); t2=clock(); t2-t1 7.1394886780303182 s1 == s2 True (This recursive algorithm, by the way, is actually faster than str() even with the slow builtin divmod.) Would there be any interest in porting these algorithms to C and using them in the standard Python long implementation? There are likely some problems that I have overlooked. A critical review will be most welcome. -- components: Interpreter Core messages: 70309 nosy: fredrikj severity: normal status: open title: Asymptotically faster divmod and str(long) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3451 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3451] Asymptotically faster divmod and str(long)
Changes by Facundo Batista [EMAIL PROTECTED]: -- nosy: +marketdickinson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3451 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Skip Montanaro [EMAIL PROTECTED] added the comment: I should also point out that I've generally used this technique to populate the fieldnames attribute from the file: f = open(somefile.csv, rb) rdr = csv.DictReader(f, fieldnames=csv.reader(f).next()) So it is fairly trivial to set the fieldnames attribute before actually reading any data rows. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Nick Coghlan [EMAIL PROTECTED] added the comment:
Like Raymond, I have issues with the idea of implicitly reading the
headers in __init__, but would be fine with the idea of a separate
method in 2.7/3.1.
As far as working around the absence of such a method goes, I personally
use itertools.chain if I happen to need the headers before I start
iterating:
r = csv.DictReader(open('test.csv'))
first = next(r)
# Do something with r.fieldnames
for row in chain(first, r):
# Do something with each row
--
nosy: +ncoghlan
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3436
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
