[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
Martin v. Löwis [EMAIL PROTECTED] added the comment: Ping. Does the problem still exist in 2.6a2? It shouldn't. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2256 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: And, a __hash__ method should be added. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2605] Descriptor instance attributes not interpreted consistently
New submission from Piet Delport [EMAIL PROTECTED]: Short version: __get__/__set__/__delete__ attributes on descriptor objects (as opposed to their types) are treated inconsistently as part of the descriptor protocol: the documentation and support code includes them; the core implementation doesn't. Example: class D(object): __get__ = lambda self, i, o: 'D' class C(object): d = D() d.__get__ = lambda i, o: 'd' d.__set__ = lambda i, v: 1/0 c = C() According to pydoc and inspect, and the description in the reference manual (section 3.4.2.3), d's __get__ and __set__ override D's: inspect.isdatadescriptor(C.__dict__['d']) True help(C) class C(__builtin__.object) | Data descriptors defined here: ... | d type(c).__dict__['d'].__get__(c, type(c)) 'd' type(c).__dict__['d'].__set__(c, 5) ZeroDivisionError: integer division or modulo by zero According to CPython, they have no effect: c.d 'D' c.d = 5; c.d 5 PEP 252 notes: For speed, the get and set methods are type slots, which points to the CPython behavior being an intentional concession for performance. Should CPython respect descriptor object attributes, if reasonable performance can be maintained? Otherwise, should the documentation and support code be changed to ignore them? -- components: Interpreter Core, Library (Lib) messages: 65289 nosy: pjd severity: normal status: open title: Descriptor instance attributes not interpreted consistently type: behavior versions: 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.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2605 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2606] trace module crashes due to using wrong sort idiom
New submission from Mark Summerfield [EMAIL PROTECTED]: In Py30a4's trace.py there is this: calls = self.calledfuncs.keys() calls.sort() which causes: AttributeError: 'dict_keys' object has no attribute 'sort' There are two other occurrences of this idiom in trace.py (just search for .sort). I guess they should be easy to fix. -- components: Library (Lib) messages: 65290 nosy: mark severity: normal status: open title: trace module crashes due to using wrong sort idiom type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2606 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Thu, Apr 10, 2008 at 3:16 AM, Amaury Forgeot d'Arc [EMAIL PROTECTED] wrote: And, a __hash__ method should be added. See issue2268 for a slice.__hash__ implementation which should work for range as well. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1297] pyconfig.h not compatible with MS VC++ Express Edition
Fred L. Drake, Jr. [EMAIL PROTECTED] added the comment: On Apr 9, 2008, at 3:07 PM, Martin v. Löwis wrote: Fred, can you remember what the rationale was? No; sorry. I didn't even remember that I'd ever built Python on Windows. Some things I've blocked out. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1297 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2606] trace module crashes due to using wrong sort idiom
Guilherme Polo [EMAIL PROTECTED] added the comment: I've changed them to sorted(obj.keys()) -- keywords: +patch nosy: +gpolo Added file: http://bugs.python.org/file9996/issue_2606.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2606 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n() and PyNumber_Index.
Trent Nelson [EMAIL PROTECTED] added the comment: Committed patch in r62269. I'll raise a separate tracker issue for PyLong_AsSsize_t as it isn't related to this issue. -- assignee: - Trent.Nelson keywords: +64bit resolution: - fixed status: open - closed title: Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. - Issues with getargs_n() and PyNumber_Index. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2440 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Alexander Belopolsky [EMAIL PROTECTED] added the comment: My guess is that this is due to the fact that strings cache their hash values while tuples don't. IIRC, caching tuple's hash values has been proposed and rejected some time ago. Furthermore, dict lookups are heavily optimized for the case when all keys are strings. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2607 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
Guido van Rossum [EMAIL PROTECTED] added the comment: Hi Amaury, thanks for your work on this. I applied your patch and looked at the code but there seem to be some issues left still. (1) I don't think you need to add a warning to classic classes that define __eq__ without __hash__ -- these aren't hashable and never were. The problem is purely with new classes AFAICT. (2) I can't seen to trigger the warning for new classes (and yes, I specified -3 on the command line :-): class C(object): ... def __eq__(self, other): return False ... hash(C()) -134976284 (3) test_Hashable in test_collections.py fails. This is because the Hashable class believes that list, set, and dict are hashable. Something odd is going on: list.__hash__([]) -135100116 but hash([]) Traceback (most recent call last): File stdin, line 1, in module TypeError: unhashable type: 'list' Note that in 2.5, both raise TypeError. -- assignee: - amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2235 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
Guido van Rossum [EMAIL PROTECTED] added the comment: Note: some more tests also fail: test_descr, test_quopri, test_set __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2235 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2609] Tests fail if ./@test is not writeable
New submission from Alexander Belopolsky [EMAIL PROTECTED]: If @test file is not writable in the current directory, test_support.TESTFN is changed to '/tmp/@test', but several tests fail if TESTFN is an absolute path: $ mkdir @test $ make test .. 4 tests failed: test_import test_site test_urllib test_zipfile .. For example, $ ./python -E -tt ./Lib/test/regrtest.py -l test_urllib test_urllib test test_urllib failed -- Traceback (most recent call last): File Lib/test/test_urllib.py, line 84, in test_geturl self.assertEqual(self.returned_obj.geturl(), self.pathname) AssertionError: 'file:///tmp/@test' != '/tmp/@test' Note that I discovered this problem after (probably killed) test_os left @test/ directory behind. It took me a while to realize what happened. I think the simplest fix is to os.chdir to '/tmp' if @test is not writable instead of changing TESTFN. Other solutions may include deleting or renaming @test with a warning when it exists, using tempnam() instead of @test and bailing out if cwd is not writeable etc. -- components: Tests messages: 65301 nosy: belopolsky severity: normal status: open title: Tests fail if ./@test is not writeable type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2609 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
David Remahl [EMAIL PROTECTED] added the comment: I submit that a check for negative values (non-assert-based) should be added to PyString_FromStringAndSize(). This API is called from many, many places, and in several cases the operand could probably be negative. It should raise an overflow exception for a negative value. -- nosy: +chmod007 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Thu, Apr 10, 2008 at 1:17 PM, David Remahl [EMAIL PROTECTED] wrote: I submit that a check for negative values (non-assert-based) should be added to PyString_FromStringAndSize(). See issue2587 and r62262. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Wed, Apr 9, 2008 at 8:18 PM, Guido van Rossum [EMAIL PROTECTED] wrote: [*sigh* i wish we didn't use a signed size type all over the place] What would you use for error returns then? res == (size_t)-1 or res == 0 PyErr_Occured() __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
Guido van Rossum [EMAIL PROTECTED] added the comment: Let's try to have this resolved before the next release. Also let's try not to accidentally merge the 2.6 changes related to this issue into 3.0. :-) -- priority: high - release blocker __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2235 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
Changes by David Remahl [EMAIL PROTECTED]: -- nosy: +chmod007 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
Justin Ferguson [EMAIL PROTECTED] added the comment:
The use of signed integers in Python is (imho) the single largest threat
to the security of the interpreter. I'm probably preaching to the choir
there though.
I really dislike have to return values and indicate error in the return
value, its really unclean and causes weirdness, for instance if you
follow PyArg_ParseTuple() down and you have an integer (or maybe it was
long?) argument, you can't actually get a value of -1 because one of the
string-int conversion routines uses that to indicate failure. The check
wrapped around it was something along the lines of:
if (-1 == retval PyErr_Occurred())
In turn down the line somewhere (I didn't follow the code path), this
value got converted to 1, so for instance doing
__import__('zlib').decompressobj().flush(-1) wouldn't trigger that bug,
it would flush 1 byte, not UINT_MAX as I had expected
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2587
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi, I'd like to know the status of this issue. I'm having the same problems here with PPC64, and the patch that Bob Atkins has sent works fine for me too. Would you intend to apply this patch in upstream? Thanks in advance. -- nosy: +sergiodj _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2606] trace module crashes due to using wrong sort idiom
Martin v. Löwis [EMAIL PROTECTED] added the comment: I've further simplified the code by eliminating the local variables, and committed that as r62270. -- nosy: +loewis resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2606 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Changes by Martin v. Löwis [EMAIL PROTECTED]: Added file: http://bugs.python.org/file/a.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2607 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Martin v. Löwis [EMAIL PROTECTED] added the comment: I'd like to know the status of this issue. I'm having the same problems here with PPC64, and the patch that Bob Atkins has sent works fine for me too. Would you intend to apply this patch in upstream? Thanks in advance. It's difficult to tell whether the patch can be applied until it is reviewed. Until then, this issue will stay open. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
Gregory P. Smith [EMAIL PROTECTED] added the comment: The asserts can go. I left them in figuring a crashing interpreter on a debug build in someones sandbox or on a buildbox would get more attention than a SystemError being raised. I doubt that is a worthy assumption on my part. Both a crash and a SystemError are notable events. shall I get rid of the asserts? As for why i dislike signed size types... tons of reasons: * It wastes half the range of the integer. * It leads to security bugs. * on return values -1 and 0 tests may be convenient to type but they could just as easily compare to a known value defined as a constant; all the things alexander belopolsky suggested. * sizes being passed -in- to a function never need to be negative meaning safe code requires extra checks like these. * sign extension of values going between registers of different sizes is needlessly expensive on some cpu architectures. use unsigned types whenever possible for the best code. anyways, I figure the Python C API is already set in stone using the signed types so its too late to fix it without causing headaches around the world. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
Gregory P. Smith [EMAIL PROTECTED] added the comment: asserts nuked. r62271 and r62272 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Thu, Apr 10, 2008 at 3:48 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Maybe as the first step we could get rid of the size sign abuse in long integer objects. I would suggest reserving a bit in the first (or last) digit to carry the sign. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
New submission from Brad Miller [EMAIL PROTECTED]: I use Python in my CS1 and CS2 curriculum and I have a question. As I've been using the Python 3.0 alphas one of the things that I am bothered by is that I cannot see the sequence produced by range without introducing students to the list() function. I typically introduce range on day 1 of class and show students what it produces without making a big deal out of the fact that it creates a list. They all accept this and things work out nicely when I introduce lists for real in a week or two. My question is why couldn't the __str__ method for the range object be more friendly and show a representation of the sequence? I understand why __repr__ should return range(0,10) for an object created using range(10) but couldn't print(range(10)) produce [0, 1, 2, ... 9] The ... could even be used if the sequence were excessively long. I have attached a patch, which follows the suggestion from Guido on how to format the string so it is not confused with a list. This is my first attempt at patching any part of the C code for Python. Please let me know what should be changed and If I've missed something. In particular I wonder whether I should be nesting any calls to PyNumber functions or whether temporary variables should be used to avoid leaking memory? In addition I get the following warning on the line where I install the range_str function in the PyRange_Type array. Objects/rangeobject.c:357: warning: initialization from incompatible pointer type Brad -- components: Interpreter Core files: range_str.patch keywords: patch messages: 65316 nosy: bmiller severity: normal status: open title: string representation of range type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file1/range_str.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi Martin, Thanks for your quick answer. I'd like to know what can we do to push this patch into upstream. Does the fact that the patch is posted in a bug report (and not in a developer's mailing list) is slowing down the reviewing process? Regards. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Benjamin Peterson [EMAIL PROTECTED] added the comment: Including __hash__ in this patch. Alexander, thanks; that could worked perfectly. Added file: http://bugs.python.org/file10001/range_eq3.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2221] Py30a3: eval in threaded code raises SystemError
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I think this is good enough: you should not invoke python code with a pending exception set (PyErr_Occurred()). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2221 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Martin v. Löwis [EMAIL PROTECTED] added the comment: I use Python in my CS1 and CS2 curriculum and I have a question. At this point, I would have almost stopped reading - the tracker is not a place for questions. I read on and then noticed that you have a patch also, not just a question :-) This is my first attempt at patching any part of the C code for Python. Please let me know what should be changed and If I've missed something. The formatting of the C code is wrong in on place (there must not be a space after the opening or before the closing parenthesis); I would also drop the space after the and before the in the result. Please try to avoid replicating code as much as possible. Rather than this complex muliply/add code, use range_item(r, 1), range_item(r, 2), range_item(r, -2), range_item(r, -1). Use range_length to find out how many things are in the range, and then again range_item for the 0..7th element. Don't use PyUnicode_FromFormat for a single %R; use PyObject_Repr instead. The code leaks many object references. Almost any function you call produces a new reference, and you have to decref it after you don't need the value anymore. E.g. write repr = PyObject_Repr(nth); appended = PyUnicode_Concat(result, repr); Py_DECREF(repr); // not needed anymore, so release it Py_DECREF(result); // about to assign to result, so release old value result = appended; Consider exceptions. About any function returning PyObject* can fail with an exception, if for not other reason than being out-of-memory. Don't forget to release partial results in case an exception, making your code like repr = PyObject_Repr(nth); if (!repr) goto fail; appended = PyUnicode_Concat(result, repr); if (!appended) goto fail; Py_DECREF(repr); Py_DECREF(result); result = appended; ... fail: Py_XDECREF(repr); Py_XDECREF(appended); ... return NULL; As we don't know in the failure case easily whether appended was already assigned to, we use XDRECREF; don't forget to initialize appended with NULL. As both the success case and the failure case end with a long list of DECREFs, it is common to phrase that as PyObject *result = NULL; ... result = what_shall_i_really_return; what_shall_i_really_return = NULL; fail: lots_of_xdecrefs; return result; In your case, it might be useful to create an array of up to 7 PyObject*, zero-initialize that, and put the partial results in there; then XDECREF that in a loop at the end. HTH, Martin -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1649238] potential clash with C++ in ceval.h
Changes by A.M. Kuchling [EMAIL PROTECTED]: -- keywords: +easy _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1649238 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Martin v. Löwis [EMAIL PROTECTED] added the comment: Thanks for your quick answer. I'd like to know what can we do to push this patch into upstream. Does the fact that the patch is posted in a bug report (and not in a developer's mailing list) is slowing down the reviewing process? No, it's the lack of reviewers in the first place that is slowing all patches, not just this one. I'm skeptical about this patch. We already have BASECFLAGS, and blindly copying @CFLAGS@ into CFLAGS might break things if configure also decides to add the same or conflicting flags. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
Jim Kleckner [EMAIL PROTECTED] added the comment: I hadn't seen any comment here that I should try it again until your question (that was why the ping). I did try it again and my application worked. Thanks! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2256 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n() and PyNumber_Index.
Benjamin Peterson [EMAIL PROTECTED] added the comment: Trent, that commit broke several tests (test_builtin for one) that relied on a floats not being interpreted as longs. -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2440 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2256 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n() and PyNumber_Index.
Trent Nelson [EMAIL PROTECTED] added the comment:
Eek, so it does, thanks. Applied the following patch on a bunch of 32-
bit/x64 systems, testing now, so far everything looks good...
Index: abstract.c
===
--- abstract.c (revision 62279)
+++ abstract.c (working copy)
@@ -1240,7 +1240,7 @@
return NULL;
}
}
- else if (m m-nb_int != NULL) {
+ else if (m m-nb_int != NULL m-nb_float == NULL) {
result = m-nb_int(item);
if (result !PyLong_Check(result)) {
PyErr_Format(PyExc_TypeError,
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2440
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n() and PyNumber_Index.
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks for fixing that. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2440 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2240] setitimer, getitimer wrapper
Changes by Trent Nelson [EMAIL PROTECTED]: -- nosy: +Trent.Nelson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2240 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.
New submission from Trent Nelson [EMAIL PROTECTED]: It'd be nice if there was a facility to force a particular test to be re-run in verbose mode with the most recent build via the buildbot web interface. It would allow us to get a bit more information about what's going on when the buildbots report stuff like this: test_property test_cprofile test_signal command timed out: 1800 seconds without output, killing pid 214235 SIGKILL failed to kill process using fake rc=-1 program finished with exit code -1 Neal or Martin, if neither of you have the desire/bandwidth to look into this, I'm more than happy to take it on. Suspect it'd involve a buildbot change on dinsdale right? -- components: Build messages: 65328 nosy: Trent.Nelson, loewis, nnorwitz severity: normal status: open title: Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode. type: feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2611 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Here is a new patch, all tests pass. - no warning for classic classes - added tests for -3 warnings I had to add two TPSLOT entries to the slodefs list; can you please check that this is correct (I wanted to reset tp_hash to NULL when __eq__ or __cmp__ are defined). Added file: http://bugs.python.org/file10002/inherit_hash3.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2235 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller [EMAIL PROTECTED] added the comment: Thanks for all of the help. Using range_item certainly simplified my job. Although I more than made up for it with all of the decref and error checking calls. One side effect of using range_item is that str(range(...)) is now subject to the same errors as indexing into really big range: for example: x = range(100) x[1] File stdin, line 1, in module OverflowError: Python int too large to convert to C ssize_t In a world where ints and long ints have been unified the existence of this error seems like a bug. I think the right thing would be to fix range_item and range_length so they do not use Py_ssize_t for the length of the range. But I may be in over my head on that guess. I also discovered that range_item does not work with negative indices. I have been poking around the tests and added some simple tests to the test_range.py class as well. I assume I should submit a patch for that as well? I have attached a new patch for rangeobject.c Brad Added file: http://bugs.python.org/file10003/range_str_2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2612] file.tell() returns Long usually, Int if subclassed
New submission from Darryl Dixon [EMAIL PROTECTED]:
Compare:
class y(file):
... def __init__(self, name):
... file.__init__(self, name)
... def __len__(self):
... self.seek(0, 2)
... return self.tell()
...
n = y('/tmp/longfile')
len(n)
364773376
Versus:
class z:
... def __init__(self, name):
... self.f = file(name, 'r')
... def __len__(self):
... self.f.seek(0, 2)
... return self.f.tell()
...
x = z('/tmp/longfile')
len(x)
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: __len__() should return an int
Because:
x = file('/tmp/longfile')
type(x.tell())
type 'long'
--
components: Library (Lib)
messages: 65331
nosy: esrever_otua
severity: normal
status: open
title: file.tell() returns Long usually, Int if subclassed
type: behavior
versions: Python 2.4
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2612
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Andreas Eisele [EMAIL PROTECTED] added the comment:
Sorry for not giving a good example in the first place.
The problem seems to appear only in the presence of
sufficiently many distinct tuples. Then I see performance
that looks rather like O(n*n)
Here is an example that shows the problem:
from time import clock
d = {}
t0 = clock()
for i in range(5):
for j in range(i*100,(i+1)*100):
d[str(j),str(j)]=j
print clock()-t0
13.04
39.51
81.86
134.18
206.66
The same example with str(j)+str(j) works fine.
Sorry if this should be a non-issue. For me it is a
reason to implement functionality in C or Perl
that I would really love to do in Python.
I would call such a thing a performance bug, but
maybe I'm just too demanding...
Best regards,
Andreas
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2607
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2612] file.tell() returns Long usually, Int if subclassed
Benjamin Peterson [EMAIL PROTECTED] added the comment:
This is because y is a new-style class (because file is) and z is not.
If the return type of new-style classe's len is not an int, Python tries
to convert it, which is why that works for the first example. However,
that conversion doesn't happen in old-style classes. Try:
class z(object):
... def __init__(self, name):
... self.f = file(name, 'r')
... def __len__(self):
... self.f.seek(0, 2)
... return self.f.tell()
x = z('/tmp/longfile')
len(x)
[Whatever it is]
--
nosy: +benjamin.peterson
resolution: - invalid
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2612
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2612] file.tell() returns Long usually, Int if subclassed
Darryl Dixon [EMAIL PROTECTED] added the comment: Thanks Benjamin, that is a very interesting feature that I can't find documented anywhere. Is there perhaps a documentation bug that can arise from this? There are various places where the differences between old and new-style classes are documented to a greater or lesser degree, eg: http://www.python.org/download/releases/2.2.3/bugs/ Is this documented somewhere currently that I missed, or could it be incorporated somewhere? thanks, D __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2612 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
