[ python-Bugs-1653753 ] crash / abort during install
Bugs item #1653753, was opened at 2007-02-07 01:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653753&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: SAndreason (sandreas41) Assigned to: Nobody/Anonymous (nobody) Summary: crash / abort during install Initial Comment: linux-2.4.33 installing Python-2.5.tar.bz2 9357099 bytes After a successful make, su # make install ...[clip]... PYTHONPATH=/usr/local/lib/python2.5 \ ./python -Wi -tt /usr/local/lib/python2.5/compileall.py \ -d /usr/local/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /usr/local/lib/python2.5 Listing /usr/local/lib/python2.5 ... Compiling /usr/local/lib/python2.5/BaseHTTPServer.py ... ...[clip]... Compiling /usr/local/lib/python2.5/xmlrpclib.py ... Compiling /usr/local/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Can installation be finished manually? or is there a patch or workaround for this? Stewart -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-07 08:41 Message: Logged In: YES user_id=849994 Originator: NO Please check if your issue is the same as http://python.org/sf/1594809, i.e. if you have PYTHON* environment variables set while compiling, which is not supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653753&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653940 ] popen - wrong order on fileobjects in tuple returned
Bugs item #1653940, was opened at 2007-02-07 10:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Emil Lind (noflux) Assigned to: Nobody/Anonymous (nobody) Summary: popen - wrong order on fileobjects in tuple returned Initial Comment: http://docs.python.org/lib/module-popen2.html (child_stdout, child_stdin, child_stderr) should probably be (child_stdin, child_stdout, child_stderr) and so on. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653940&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653940 ] popen - docs - wrong order on fileobjects in tuple returned
Bugs item #1653940, was opened at 2007-02-07 10:25 Message generated for change (Settings changed) made by noflux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Emil Lind (noflux) Assigned to: Nobody/Anonymous (nobody) >Summary: popen - docs - wrong order on fileobjects in tuple returned Initial Comment: http://docs.python.org/lib/module-popen2.html (child_stdout, child_stdin, child_stderr) should probably be (child_stdin, child_stdout, child_stderr) and so on. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653940&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653753 ] crash / abort during install
Bugs item #1653753, was opened at 2007-02-06 17:56 Message generated for change (Comment added) made by sandreas41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653753&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: SAndreason (sandreas41) Assigned to: Nobody/Anonymous (nobody) Summary: crash / abort during install Initial Comment: linux-2.4.33 installing Python-2.5.tar.bz2 9357099 bytes After a successful make, su # make install ...[clip]... PYTHONPATH=/usr/local/lib/python2.5 \ ./python -Wi -tt /usr/local/lib/python2.5/compileall.py \ -d /usr/local/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /usr/local/lib/python2.5 Listing /usr/local/lib/python2.5 ... Compiling /usr/local/lib/python2.5/BaseHTTPServer.py ... ...[clip]... Compiling /usr/local/lib/python2.5/xmlrpclib.py ... Compiling /usr/local/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Can installation be finished manually? or is there a patch or workaround for this? Stewart -- >Comment By: SAndreason (sandreas41) Date: 2007-02-07 08:04 Message: Logged In: YES user_id=1095971 Originator: YES Ah! That is the same problem. Works for me. Thank you -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-07 00:41 Message: Logged In: YES user_id=849994 Originator: NO Please check if your issue is the same as http://python.org/sf/1594809, i.e. if you have PYTHON* environment variables set while compiling, which is not supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653753&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1654367 ] [PATCH] Debuggers need a way to change the locals of a frame
Feature Requests item #1654367, was opened at 2007-02-07 17:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] Debuggers need a way to change the locals of a frame
Initial Comment:
Debuggers need a way to change the local variables in a given frame...
currently, this works only if this change is done in the topmost frame (and
under certain circumstances), but it should work for any frame.
Initial discussion at:
http://mail.python.org/pipermail/python-dev/2007-February/070884.html
Apparently, the problem is the order in which PyFrame_LocalsToFast /
PyFrame_FastToLocals is called.
The proposed solution to this is having a savelocals() method in the frame
object and have it reflect the changes in its returned dict into its locals. It
will simply enable users to call PyFrame_LocalsToFast externally after a
change, to be sure that it will not be changed (and it must be done before
another call to PyFrame_LocalsToFast -- which I don't see as a large problem,
because it is of restrict use -- mainly for debuggers).
- frameobject.c Patch part 1: -
static PyObject *
PyFrame_SaveLocals(PyFrameObject *f)
{
PyFrame_LocalsToFast(f, 0);
Py_INCREF(Py_None);
return Py_None;
}
static PyMethodDef frame_methodlist[] = {
{"savelocals", (PyCFunction)PyFrame_SaveLocals, METH_NOARGS,
"After a change in f_locals, this method should be called to save the
changes internally."
},
{NULL} /* Sentinel */
};
-- frameobject.c Patch part 2: ---
Add to PyTypeObject PyFrame_Type:
frame_methodlist,/* tp_methods */
-- end patch -
I'm sorry that this is not in an actual patch format... but as I didn't get it
from the cvs, it is easier for me to explain it (as it is a rather small patch).
Attached is a test-case for this patch.
Thanks,
Fabio
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1654408 ] Installer should split tcl/tk and tkinter install options.
Bugs item #1654408, was opened at 2007-02-07 11:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654408&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ron Adam (ron_adam) Assigned to: Martin v. Löwis (loewis) Summary: Installer should split tcl/tk and tkinter install options. Initial Comment: On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python. Selecting to not install tcl/tk with the installer also removes tkinter, and idle. Which is what you don't want in this case. To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following: - python/tcl directory - python/dlls/tcl84.dll - python/dlls/tk84.dll - python/dlls/tclpip84.dll (or the corresponding versions) And then make sure tcl's bin directory is in the path. This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1654429 ] thread join() with timeout hangs on Windows 2003 x64
Bugs item #1654429, was opened at 2007-02-07 18:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: bentoi (bentoi) Assigned to: Nobody/Anonymous (nobody) Summary: thread join() with timeout hangs on Windows 2003 x64 Initial Comment: If join() is called on a thread which is alive with a timeout, it hangs for the duration of the timeout even if the thread terminated before. This appears to only happen on Windows 2003 x64. Here's a test case: --- #!/usr/bin/env python from threading import Thread import time class ReaderThread(Thread): def __init__(self): Thread.__init__(self) def run(self): print "sleeping" time.sleep(5) print "finished sleeping" thread = ReaderThread() thread.start() print "joining..." thread.join(60) print "joined" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1654408 ] Installer should split tcl/tk and tkinter install options.
Bugs item #1654408, was opened at 2007-02-07 18:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654408&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ron Adam (ron_adam) Assigned to: Martin v. Löwis (loewis) Summary: Installer should split tcl/tk and tkinter install options. Initial Comment: On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python. Selecting to not install tcl/tk with the installer also removes tkinter, and idle. Which is what you don't want in this case. To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following: - python/tcl directory - python/dlls/tcl84.dll - python/dlls/tk84.dll - python/dlls/tclpip84.dll (or the corresponding versions) And then make sure tcl's bin directory is in the path. This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-07 22:14 Message: Logged In: YES user_id=21627 Originator: NO I cannot understand why Python's Tkinter becomes unstable when Tcl is installed, or vice versa. Are you setting any environment variables (like TCL_HOME)? You should not do that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1575169 ] isSequenceType returns True for dict subclasses (<> 2.3)
Bugs item #1575169, was opened at 2006-10-11 05:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Gfeller (gfe) Assigned to: Raymond Hettinger (rhettinger) Summary: isSequenceType returns True for dict subclasses (<> 2.3) Initial Comment: The following behavior is correct according to the documentation. However, it seems weird to me, and broke my code when going from 2.3 to 2.4: Python 2.4.2: >>> import operator >>> class deriveddict(dict): pass ... >>> d =dict() >>> dd = deriveddict() >>> operator.isSequenceType(d) False >>> operator.isSequenceType(dd) True The last statement returns False in Python 2.3.4. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-02-07 17:24 Message: Logged In: YES user_id=80475 Originator: NO Fixed in revisions 53661 and 53662. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-27 13:28 Message: Logged In: YES user_id=80475 Originator: NO Hmm, it may be possible to make the test smarter by checking base classes known mappings or known sequences in cases where the __getitem__ method hasn't been overridden. That would reduce false positives in cases like this where there is some hint as to whether the __getitem__ method is for mapping or for sequence behavior. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1326277 ] itertools.count wraps around after maxint
Feature Requests item #1326277, was opened at 2005-10-13 18:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326277&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.count wraps around after maxint Initial Comment: See below. This goes against the notion of int/long unification and can cause weird unexpected behavior, almost like a buffer overflow. It should promote to a long at the appropriate time, or that's not feasible, then raise an exception, don't wrap around silently. Xrange is also not so great about this. It at least raises an exception if you give it too large an endpoint, but promoting to long would be better. Steven D'Aprano and others on clpy pointed this out. >>> from itertools import count >>> b=2**31 - 3 >>> c = count(b) >>> for i in range(5): ...print c.next() ... 2147483645 2147483646 2147483647 -2147483648 -2147483647 >>> -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-02-07 19:07 Message: Logged In: YES user_id=80475 Originator: NO Nows raises an OverflowError instead of silently wrapping around. See revisions 53665 and 53666. -- Comment By: paul rubin (phr) Date: 2005-10-14 10:11 Message: Logged In: YES user_id=72053 You're right, the docs do describe that behavior of itertools.count (someone on clpy thought otherwise, IIRC). I don't see anything in http://docs.python.org/lib/built-in-funcs.html about what enumerate does. It looks my p3-750 can enumerate about 400k iterations of itertools.repeat(None) per second, so it can reach maxint in about 1.5 hours, but I don't feel like running it that long to see what happens. At minimum, enumerate's doc should be updated to say what it does. I suppose it's a matter of opinion but I'd take the view that both of these wraparounds (assuming enumerate wraps around) are bugs even if they're documented bugs. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-14 02:12 Message: Logged In: YES user_id=80475 It's not a bug -- it is the documented behavior. The simple work-around is to roll your own generators: def count(n): while 1: yield n n += 1 def enumerate(iterable): c = 0 for elem in iterable: yield (c, elem) c += 1 Will look at possibly enhancing this for Py2.5. -- Comment By: paul rubin (phr) Date: 2005-10-14 00:53 Message: Logged In: YES user_id=72053 If both fixes are feasible then promoting to long is definitely the correct one. Raising an exception is just a kludge to at least not do something horrible silently. However, on a fast 32 bit machine, counting past 2**31 or something is quite realistic. A web server might send out that many packets in a few days or weeks. It shouldn't crash or go crazy after running for a long time and overflowing maxint. It occurs to me, the enumerate iterator should also be checked and fixed if needed. It, too, can overflow maxint if counting something like a network stream. Maybe there are some more iterators besides these, which need the same attention. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-14 00:18 Message: Logged In: YES user_id=33168 I agree something should be done. Raymond, which behaviour would you prefer? I can implement if you want (just let me know and assign back to me). BTW, I don't have the same problem. I need to set b = 2**63 - 3 :-) (using current CVS). -- Comment By: paul rubin (phr) Date: 2005-10-13 18:29 Message: Logged In: YES user_id=72053 I forgot to say, the test example is Python 2.4.1 on linux. I don't know if 2.4.2 has a fix. I don't see anything about it in the database. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512504 ] builtin enumerate overflows
Bugs item #1512504, was opened at 2006-06-26 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: James Harlow (hythloday) Assigned to: Raymond Hettinger (rhettinger) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-02-07 19:08 Message: Logged In: YES user_id=80475 Originator: NO Nows raises an OverflowError instead of silently wrapping around. See revisions 53665 and 53666. -- Comment By: James Harlow (hythloday) Date: 2006-06-27 02:25 Message: Logged In: YES user_id=458963 Fair enough, I take your points both about the ease of making a new generator. Is it possible to make the existing one a bit less surprising, though, by having it raise an exception when it wraps? I'm at a loss to think of any algorithm that would work correctly when it wraps, so a new exception wouldn't be a change in interface rally. ;) Failing that, is it possible to document it? -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-27 00:13 Message: Logged In: YES user_id=80475 You're correct. The behavior was by design, emphasizing speed and simplicity over a toy limiting case. If some app actually requires enumeration of over 2**31 objects, it is trivial to write a generator that gives the desired flexibility. Of course, on 64 bit machines, the limit is a bit higher ;-) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 22:22 Message: Logged In: YES user_id=33168 Raymond, any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1326277 ] itertools.count wraps around after maxint
Feature Requests item #1326277, was opened at 2005-10-13 18:27 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326277&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.count wraps around after maxint Initial Comment: See below. This goes against the notion of int/long unification and can cause weird unexpected behavior, almost like a buffer overflow. It should promote to a long at the appropriate time, or that's not feasible, then raise an exception, don't wrap around silently. Xrange is also not so great about this. It at least raises an exception if you give it too large an endpoint, but promoting to long would be better. Steven D'Aprano and others on clpy pointed this out. >>> from itertools import count >>> b=2**31 - 3 >>> c = count(b) >>> for i in range(5): ...print c.next() ... 2147483645 2147483646 2147483647 -2147483648 -2147483647 >>> -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-02-07 19:07 Message: Logged In: YES user_id=80475 Originator: NO Nows raises an OverflowError instead of silently wrapping around. See revisions 53665 and 53666. -- Comment By: paul rubin (phr) Date: 2005-10-14 10:11 Message: Logged In: YES user_id=72053 You're right, the docs do describe that behavior of itertools.count (someone on clpy thought otherwise, IIRC). I don't see anything in http://docs.python.org/lib/built-in-funcs.html about what enumerate does. It looks my p3-750 can enumerate about 400k iterations of itertools.repeat(None) per second, so it can reach maxint in about 1.5 hours, but I don't feel like running it that long to see what happens. At minimum, enumerate's doc should be updated to say what it does. I suppose it's a matter of opinion but I'd take the view that both of these wraparounds (assuming enumerate wraps around) are bugs even if they're documented bugs. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-14 02:12 Message: Logged In: YES user_id=80475 It's not a bug -- it is the documented behavior. The simple work-around is to roll your own generators: def count(n): while 1: yield n n += 1 def enumerate(iterable): c = 0 for elem in iterable: yield (c, elem) c += 1 Will look at possibly enhancing this for Py2.5. -- Comment By: paul rubin (phr) Date: 2005-10-14 00:53 Message: Logged In: YES user_id=72053 If both fixes are feasible then promoting to long is definitely the correct one. Raising an exception is just a kludge to at least not do something horrible silently. However, on a fast 32 bit machine, counting past 2**31 or something is quite realistic. A web server might send out that many packets in a few days or weeks. It shouldn't crash or go crazy after running for a long time and overflowing maxint. It occurs to me, the enumerate iterator should also be checked and fixed if needed. It, too, can overflow maxint if counting something like a network stream. Maybe there are some more iterators besides these, which need the same attention. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-14 00:18 Message: Logged In: YES user_id=33168 I agree something should be done. Raymond, which behaviour would you prefer? I can implement if you want (just let me know and assign back to me). BTW, I don't have the same problem. I need to set b = 2**63 - 3 :-) (using current CVS). -- Comment By: paul rubin (phr) Date: 2005-10-13 18:29 Message: Logged In: YES user_id=72053 I forgot to say, the test example is Python 2.4.1 on linux. I don't know if 2.4.2 has a fix. I don't see anything about it in the database. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1619060 ] bisect on presorted list
Feature Requests item #1619060, was opened at 2006-12-19 16:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1619060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Extension Modules >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) Assigned to: Raymond Hettinger (rhettinger) Summary: bisect on presorted list Initial Comment: The python and c implementation of bisect do not support custom-sorted lists using the list.sort method. In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort. This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element. In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order. The change imposes 3 new branch conditions and potential no-op function calls for when key is None. I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well. The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-19 16:43 Message: Logged In: YES user_id=80475 Originator: NO I'm -1 on this patch. At first blush it would seem nice to progagate sort's notion of a key= function; however, sort() is an all at once operation that can guarantee the function gets called only once per key. In contrast, bisect() is more granualar so consecutive calls may need to invoke the same key= function again and again. This is almost always the the-wrong-way-to-do-it (the key function should be precomputed and either stored separately or follow a decorate-sort pattern). By including custom sorting in bisect's API we would be diverting users away from better approaches. A better idea would be to create a recipe for a SortedList class that performed pre-calculated custom keys upon insertion and maintained an internal, decorated list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1619060&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1602378 ] Incorrect docs for bisect_left
Bugs item #1602378, was opened at 2006-11-24 12:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None >Priority: 4 Private: No Submitted By: Daniel Eloff (eloff) Assigned to: Raymond Hettinger (rhettinger) Summary: Incorrect docs for bisect_left Initial Comment: Quote: Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. The last sentence is incorrect, and it contradicts what comes earlier. Not knowing which is correct, I had to test it in the shell. >>> from bisect import * >>> l = [1,2,3,3,3,4,5] >>> bisect_left(l,3) 2 >>> l[2:] [3, 3, 3, 4, 5] It should be changed to read "i points at the leftmost x already there" -Dan -- Comment By: Daniel Eloff (eloff) Date: 2006-12-03 17:39 Message: Logged In: YES user_id=730918 Originator: YES That makes more sense, but if that's explained anywhere it was hidden away where I've never discovered it. I would be in favor of you're suggested fix to the line in question. -Dan -- Comment By: Tim Peters (tim_one) Date: 2006-11-24 14:16 Message: Logged In: YES user_id=31435 Originator: NO The docs are written from the POV that indices in Python point /between/ array elements, which is the easiest way to understand slices, and that there are n+1 non-negative indices that "make obvious sense" in slices of a sequence with n elements: index 0 points "just before" element a[0], and index n "just after" element a[n-1], while for 0 < i < n-1, index i points "just before" element [i] /and/ "just after" element a[i-1]. This is also the sanest way to understand the return value of the bisect functions, which again can return n+1 values given a sequence with n elements. That said, I agree the docs are cryptic if you don't understand that first. I'm not sure this is the best place to explain it. The specific line in question could be "repaired" by saying a[i] is the leftmost x already there, identifying one of the n elements instead of one of the n+1 sequence positions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1462228 ] custom comparison function for bisect module
Feature Requests item #1462228, was opened at 2006-03-31 11:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462228&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Fleming (splitscreen) Assigned to: Raymond Hettinger (rhettinger) Summary: custom comparison function for bisect module Initial Comment: This is a patch for the feature requets #1451588 The patch is from the current trunk, r43488. The patch provides the bisect module (both the python and C implementation) with an option for a custom comparison function. If not custom comparison function is provided the standard cmp() built-in function it used. Please review, any comments welcome. matt -- Comment By: Matt Fleming (splitscreen) Date: 2006-04-03 17:39 Message: Logged In: YES user_id=1126061 Jonathan Joseph kindly pointed out some redundant if statements to me. I've updated the patch with a newer version. Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462228&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Feature Requests item #1649329, was opened at 2007-01-31 18:20 Message generated for change (Comment added) made by jjinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.py incompatible with eggs Initial Comment: If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg. That's because gettext.py only knows how to find the translation catalogs in the actual filesystem. This wouldn't be so bad if the "find" function didn't serve double duty. On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks. On the other hand, it actually resolves the files in the filesystem. It would be nice if these were separate. It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem. Perhaps gettext can be updated to know about eggs. Perhaps setting localedir to something like "egg://..." would enable this functionality. -- >Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-07 16:49 Message: Logged In: YES user_id=30164 Originator: YES File Added: gettext.patch -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-06 22:45 Message: Logged In: YES user_id=21627 Originator: NO Do you have a proposal on how to do the refactoring? It would be fine to split find into two parts; it would not be acceptable (to me) to teach it egg: URLs. -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-06 14:28 Message: Logged In: YES user_id=30164 Originator: YES Sorry, yes, this is a feature request. The most important thing that I'm requesting is to refactor the code. That "find" function implements a certain algorithm that has nothing to do with the filesystem. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-06 11:43 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. gettext.find behaves as specified; if you want something else, don't use that function. If you want to load a .mo file from a zip file, you should be able to create a GNUTranslation object directly, from a file-like object. I don't think that gettext should support eggs directly. If you want it to do things other than loading from file systems, you should generalize that appropriately. One appropriate generalization could be the introduction of a directory-like object, where you can do .exists(relpath), and .open(relpath). However, introduction of directory-like objets is PEP material. Reclassifying this as a feature request. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Feature Requests item #1649329, was opened at 2007-01-31 18:20 Message generated for change (Comment added) made by jjinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.py incompatible with eggs Initial Comment: If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg. That's because gettext.py only knows how to find the translation catalogs in the actual filesystem. This wouldn't be so bad if the "find" function didn't serve double duty. On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks. On the other hand, it actually resolves the files in the filesystem. It would be nice if these were separate. It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem. Perhaps gettext can be updated to know about eggs. Perhaps setting localedir to something like "egg://..." would enable this functionality. -- >Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-07 16:52 Message: Logged In: YES user_id=30164 Originator: YES Ok, I've uploaded a patch with a possible way to refactor the code. I'm okay if you mark this bug as WONTFIX. I'm raising it as a concern because I know there are a lot of people out there using Web frameworks such as Pylons, Turbo Gears, etc. that are going to have to duplicate the code in "find" in order to use eggs. I hate to have see them do that. :-/ -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-07 16:49 Message: Logged In: YES user_id=30164 Originator: YES File Added: gettext.patch -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-06 22:45 Message: Logged In: YES user_id=21627 Originator: NO Do you have a proposal on how to do the refactoring? It would be fine to split find into two parts; it would not be acceptable (to me) to teach it egg: URLs. -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-06 14:28 Message: Logged In: YES user_id=30164 Originator: YES Sorry, yes, this is a feature request. The most important thing that I'm requesting is to refactor the code. That "find" function implements a certain algorithm that has nothing to do with the filesystem. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-06 11:43 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. gettext.find behaves as specified; if you want something else, don't use that function. If you want to load a .mo file from a zip file, you should be able to create a GNUTranslation object directly, from a file-like object. I don't think that gettext should support eggs directly. If you want it to do things other than loading from file systems, you should generalize that appropriately. One appropriate generalization could be the introduction of a directory-like object, where you can do .exists(relpath), and .open(relpath). However, introduction of directory-like objets is PEP material. Reclassifying this as a feature request. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1654408 ] Installer should split tcl/tk and tkinter install options.
Bugs item #1654408, was opened at 2007-02-07 11:50 Message generated for change (Comment added) made by ron_adam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654408&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ron Adam (ron_adam) Assigned to: Martin v. Löwis (loewis) Summary: Installer should split tcl/tk and tkinter install options. Initial Comment: On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python. Selecting to not install tcl/tk with the installer also removes tkinter, and idle. Which is what you don't want in this case. To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following: - python/tcl directory - python/dlls/tcl84.dll - python/dlls/tk84.dll - python/dlls/tclpip84.dll (or the corresponding versions) And then make sure tcl's bin directory is in the path. This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people. -- >Comment By: Ron Adam (ron_adam) Date: 2007-02-07 19:19 Message: Logged In: YES user_id=1687923 Originator: YES I think part of my problem was because of having python/dlls directory in windows file path. So that does explain some of it. Probably due to following instructions like this. http://mail.python.org/pipermail/python-win32/2002-September/000497.html It still would be nice to have the option to not install tcl/tk (but keep tkinter) and use the newest update of tcl with python. I use BLT to do graphs, and it installs fine if you remove tcl from python, install tcl and BLT together. Keeping tcl in python results in the errors reported in th e above link. And following the advice and adding python/dlls to the path can result in conflicts. Is that clearer. I know this isn't a common occurrence and not a problem with python directly. That's why I listed it as a feature request and not as a bug. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-07 15:14 Message: Logged In: YES user_id=21627 Originator: NO I cannot understand why Python's Tkinter becomes unstable when Tcl is installed, or vice versa. Are you setting any environment variables (like TCL_HOME)? You should not do that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653753 ] crash / abort during install
Bugs item #1653753, was opened at 2007-02-07 01:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653753&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: SAndreason (sandreas41) Assigned to: Nobody/Anonymous (nobody) Summary: crash / abort during install Initial Comment: linux-2.4.33 installing Python-2.5.tar.bz2 9357099 bytes After a successful make, su # make install ...[clip]... PYTHONPATH=/usr/local/lib/python2.5 \ ./python -Wi -tt /usr/local/lib/python2.5/compileall.py \ -d /usr/local/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /usr/local/lib/python2.5 Listing /usr/local/lib/python2.5 ... Compiling /usr/local/lib/python2.5/BaseHTTPServer.py ... ...[clip]... Compiling /usr/local/lib/python2.5/xmlrpclib.py ... Compiling /usr/local/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Can installation be finished manually? or is there a patch or workaround for this? Stewart -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-08 07:39 Message: Logged In: YES user_id=849994 Originator: NO Does this also fix the other bug you filed? -- Comment By: SAndreason (sandreas41) Date: 2007-02-07 16:04 Message: Logged In: YES user_id=1095971 Originator: YES Ah! That is the same problem. Works for me. Thank you -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-07 08:41 Message: Logged In: YES user_id=849994 Originator: NO Please check if your issue is the same as http://python.org/sf/1594809, i.e. if you have PYTHON* environment variables set while compiling, which is not supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653753&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
