class _fileobject: def __init__(self, sock, mode, bufsize): self._sock = sock self._mode = mode if bufsize < 0: bufsize = 512 # SP 9 Aug 2001: default _rbufsize is too small, crashing CGIHTTPServer on POST's # This fix still only allows pages of less than given buffer size to be updated, # so the real fix has still to be discovered. #self._rbufsize = max(1, bufsize) self._rbufsize = max(16*1024, bufsize) self._wbufsize = bufsize self._wbuf = self._rbuf = ""

, argc=3, ubp_av=0xbffff594, init=0x8050e78 <_init>, fini=0x80a9810 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff58c) at ../sysdeps/generic/libc-start.c:129 ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-28 07:18 Message: Logged In: YES user_id=38388 The bug is in the _index() slot: PyList_GetItem() does not increment the item's refcount for you, so you have to apply a Py_XINCREF() yourself. This is not related to the PyUnicode_Split() call in any way. Closing the report. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-09-28 06:37 Message: Logged In: YES user_id=11084 *sigh* just trying to re-upload the file. The problem seems to occur somewhere in the cleanup code when die module gets deleted or unloaded. The other unicode problem is solved. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-28 06:33 Message: Logged In: YES user_id=38388 I still don't see an archive on SF. Could this be caused by the same problem you reported a few days ago ? (using "u" instead of "U" in the argument parser ?). ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-09-28 05:43 Message: Logged In: YES user_id=11084 The archive should be available now. In Sourceforge We Trust. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-09-28 05:40 Message: Logged In: YES user_id=11084 The archive should be available now. In Sourceforge We Trust. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-09-28 05:40 Message: Logged In: YES user_id=11084 archive should be available now :-) In Sourceforge We Trust. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2001-09-28 00:17 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2001-09-28 00:17 Message: Logged In: YES user_id=21627 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465759&group_id=5470 From noreply@sourceforge.net Fri Sep 28 16:35:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 08:35:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-419062 ] python 2.1 : building pbs on AIX 4.3.2 Message-ID: Bugs item #419062, was opened at 2001-04-25 23:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.1 : building pbs on AIX 4.3.2 Initial Comment: I met what could be called "regression"? problems : the "make all" process stopped at the beginning of the building of the shared modules under AIX 4.3.2. 1. it is looking for a "ld_so_aix" under the destination directory (${prefix}/lib/python2.1}) ... which, for an obvious reason is not there during the compiling phase 2. if you try to force the process by creating the directory and putting the "so needed" program in it, a new stop occurs : it is unable to find the "Python.exp" or whatever other *.exp file needed by the linking process Those problems didn't occur during the build of python 2.0 wich has been compiled fine under AIX 4.3.2 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-28 08:35 Message: Logged In: NO nevermind. i figured it out. muchas gracias. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-27 11:08 Message: Logged In: NO Sorry for my ignorance, but can someone tell me how to apply a python patch (or point me to the doc that explains how)? ---------------------------------------------------------------------- Comment By: The Written Word (china) (tww-china) Date: 2001-09-26 10:20 Message: Logged In: YES user_id=119770 Oops. We accidentally deleted it. It's back now. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-26 09:58 Message: Logged In: NO Does anyone know where else this patch can be found? ---------------------------------------------------------------------- Comment By: The Written Word (china) (tww-china) Date: 2001-06-14 03:47 Message: Logged In: YES user_id=119770 Try the patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-419062.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:00:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:00:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-419062 ] python 2.1 : building pbs on AIX 4.3.2 Message-ID: Bugs item #419062, was opened at 2001-04-25 23:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.1 : building pbs on AIX 4.3.2 Initial Comment: I met what could be called "regression"? problems : the "make all" process stopped at the beginning of the building of the shared modules under AIX 4.3.2. 1. it is looking for a "ld_so_aix" under the destination directory (${prefix}/lib/python2.1}) ... which, for an obvious reason is not there during the compiling phase 2. if you try to force the process by creating the directory and putting the "so needed" program in it, a new stop occurs : it is unable to find the "Python.exp" or whatever other *.exp file needed by the linking process Those problems didn't occur during the build of python 2.0 wich has been compiled fine under AIX 4.3.2 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:00 Message: Logged In: YES user_id=6380 Closing. I applied the patch from "tww-china" in the CVS. (China, what's your real/full name, so we can add it to Misc/ACKS?) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-28 08:35 Message: Logged In: NO nevermind. i figured it out. muchas gracias. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-27 11:08 Message: Logged In: NO Sorry for my ignorance, but can someone tell me how to apply a python patch (or point me to the doc that explains how)? ---------------------------------------------------------------------- Comment By: The Written Word (china) (tww-china) Date: 2001-09-26 10:20 Message: Logged In: YES user_id=119770 Oops. We accidentally deleted it. It's back now. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-26 09:58 Message: Logged In: NO Does anyone know where else this patch can be found? ---------------------------------------------------------------------- Comment By: The Written Word (china) (tww-china) Date: 2001-06-14 03:47 Message: Logged In: YES user_id=119770 Try the patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-419062.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:02:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:02:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-463330 ] binascii.b2a_base64() trailing newline Message-ID: Bugs item #463330, was opened at 2001-09-20 13:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=463330&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: binascii.b2a_base64() trailing newline Initial Comment: binascii.b2a_base64() should not append a "courtesy newline". See attached patch (but the test suite should be updated too). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-28 09:02 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libbase64.tex revision 1.19. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-27 21:48 Message: Logged In: YES user_id=12800 Correct. base64.encode() and base64.encodestring() should be documented as adding a trailing newline, but only if the source string doesn't already end in a newline (i.e: base64.encodestring('hello') == base64.encodestring('hello\n') ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-23 14:57 Message: Logged In: YES user_id=3066 What in the base64 module needs to have documentation corrected? It sounds like the encode() and encodestring() functions should be documented as generating a trailing newline; is this correct? Set status to pending. Barry, when you respond to this request for information the issue will be re-opened and assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-22 10:46 Message: Logged In: YES user_id=6380 Whether or not it's documented for base64, changing that will also break existing code. It's a documentation issue (unfortunately). ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-21 20:38 Message: Logged In: YES user_id=12800 You're right, the newline is documented in b2a_base64(). I actually hit this problem through the base64 module, which uses binascii underneath. The extra newline is implied in the example, but not really documented. I think it may also be a bit misleading to quote RFC 1521 where that RFC does not (I think) require the newline. Two options: - reassign to Fred for updating the base64 documentation about the extra newline. - get rid of the extra newline in base64 only, not in binascii. This can be accomplished by looking at the source string: if it has a trailing newline, leave one in, if it doesn't strip the extra newline from the result string. That's the solution I'll use in the email package if we don't change base64. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 09:06 Message: Logged In: YES user_id=6380 But won't this break working code? I believe the courtesy newline is documented. If people program around this naively, their code will break. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=463330&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:04:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:04:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-419062 ] python 2.1 : building pbs on AIX 4.3.2 Message-ID: Bugs item #419062, was opened at 2001-04-25 23:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.1 : building pbs on AIX 4.3.2 Initial Comment: I met what could be called "regression"? problems : the "make all" process stopped at the beginning of the building of the shared modules under AIX 4.3.2. 1. it is looking for a "ld_so_aix" under the destination directory (${prefix}/lib/python2.1}) ... which, for an obvious reason is not there during the compiling phase 2. if you try to force the process by creating the directory and putting the "so needed" program in it, a new stop occurs : it is unable to find the "Python.exp" or whatever other *.exp file needed by the linking process Those problems didn't occur during the build of python 2.0 wich has been compiled fine under AIX 4.3.2 ---------------------------------------------------------------------- Comment By: The Written Word (china) (tww-china) Date: 2001-09-28 09:04 Message: Logged In: YES user_id=119770 Albert Chin-A-Young ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:00 Message: Logged In: YES user_id=6380 Closing. I applied the patch from "tww-china" in the CVS. (China, what's your real/full name, so we can add it to Misc/ACKS?) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-28 08:35 Message: Logged In: NO nevermind. i figured it out. muchas gracias. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-27 11:08 Message: Logged In: NO Sorry for my ignorance, but can someone tell me how to apply a python patch (or point me to the doc that explains how)? ---------------------------------------------------------------------- Comment By: The Written Word (china) (tww-china) Date: 2001-09-26 10:20 Message: Logged In: YES user_id=119770 Oops. We accidentally deleted it. It's back now. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-26 09:58 Message: Logged In: NO Does anyone know where else this patch can be found? ---------------------------------------------------------------------- Comment By: The Written Word (china) (tww-china) Date: 2001-06-14 03:47 Message: Logged In: YES user_id=119770 Try the patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-419062.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:08:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:08:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-465673 ] pthreads need signal protection Message-ID: Bugs item #465673, was opened at 2001-09-27 07:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465673&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: pthreads need signal protection Initial Comment: I've been playing around with Python and threads, and I've noticed some odd and often unstable behavior. In particular, on my Solaris 8 box I can get Python 1.5.2, 1.6, 2.0, or 2.1 to core dump every time with the following sequence. I've also seen this happen on Solaris 6 (all UltraSPARC based): 1. Enter the following code into the interactive interpreter: -- import threading def loopingfunc(): while 1: pass threading.Thread(target=loopingfunc).start() -- 2. Send a SIGINT signal (usually Ctrl-C, your terminal settings may vary). "Keyboard Interrupt" is displayed and so far everything looks fine. 3. Now simply press the key to enter a blank line in the interpreter. For my Solaris 8 box with the GNU readline 2.2 module present, this always ends up in a core dump. It may take a while, since at this point the readline signal handler is being re-entered recursively until the stack overflows. I've described this problem in the past on Usenet, but didn't get much response. For a more complete discussion of the problem and a possible solution, see http://groups.google.com/groups?hl=en&threadm=98osml%24sul%241%40newshost.mot.com&rnum=1&prev=/groups%3Fas_ugroup%3Dcomp.lang.python%26as_uauthors%3DJason%2520Lowe (If the URL doesn't work, search groups.google.com for posts by "Jason Lowe" in comp.lang.python and view the entire thread of the result.) Upon investigation of the problem, it looks like the problem is caused by an interaction with pthreads and signals. The SIGINT signal is delivered to the thread that is performing the spin loop, NOT the thread that is in the readline() module. Because the readline module uses setjmp()/longjmp() for its signal handling, the longjmp() ends up being executed by the wrong thread with dire results. Pthreads and signals don't mix very well, so one has to be very careful to make sure everything works properly. A typical solution is to ensure signals are only delivered to one thread by masking all signals in all other threads. I believe this will be the same root cause of bug #219772 (Interactive InterPreter+ Thread -> core dump at exit). I was able to solve the problem by modifying Python/thread_pthread.h's PyThread_start_new_thread() to block all signals with pthread_sigmask() after the new thread was started. This causes all threads created by Python except the initial thread to have all signals masked. This forces signals to be delivered to the main thread. I don't believe anyone is depending on the current behavior that signals will be delivered to an indeterminate thread, so this change seems safe. However I haven't run many other Python applications that deal with threads and signals. I propose that on platforms that implement Python threads with pthreads, the code masks all signals in all threads except the initial, main thread. This will resolve the problem of signals being delivered to threads indeterminately. I think I can dig up my initial code deltas if desired, or I can always recreate them. It's just a few lines to mask signals in the thread before thread creation, then restore them afterwards. (This causes only the main thread to have signals preserved.) A side question from this is whether the thread module (or posix module?) should expose the pthread_sigmask() functionality to Python threads on a platform that uses pthreads. This would allow developers to manipulate the signal masks of the Python threads so that a particular signal can be routed to a particular thread. (They would mask this signal in all other threads except the desired thread.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:08 Message: Logged In: YES user_id=6380 I don't have Solaris access, and I can't get this to break on Linux. But I agree with your suggestion that posix threads should block signals. Are you capable of coming up with a patch that does that, in a way that is independent of the specific platform (as long as it has PTHREADS)? You may have to open a new issue in the patch manager, since SF doesn't allow after-the-fact attachments to anonymous entries. (Maybe SF logs you out whenever you quit your browser? That's what it does for me. :-) ---------------------------------------------------------------------- Comment By: Jason Lowe (jasonlowe) Date: 2001-09-27 07:40 Message: Logged In: YES user_id=56897 Ack. SourceForge wants to log me out every few minutes, so I wasn't logged in when I submitted this. Sorry 'bout that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465673&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:10:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:10:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-419062 ] python 2.1 : building pbs on AIX 4.3.2 Message-ID: Bugs item #419062, was opened at 2001-04-25 23:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.1 : building pbs on AIX 4.3.2 Initial Comment: I met what could be called "regression"? problems : the "make all" process stopped at the beginning of the building of the shared modules under AIX 4.3.2. 1. it is looking for a "ld_so_aix" under the destination directory (${prefix}/lib/python2.1}) ... which, for an obvious reason is not there during the compiling phase 2. if you try to force the process by creating the directory and putting the "so needed" program in it, a new stop occurs : it is unable to find the "Python.exp" or whatever other *.exp file needed by the linking process Those problems didn't occur during the build of python 2.0 wich has been compiled fine under AIX 4.3.2 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:10 Message: Logged In: YES user_id=6380 Ah! You're already in our ACKS file. Thanks! (Any other patches of yours that you'd like us to have a look at?) ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin-A- (tww-china) Date: 2001-09-28 09:04 Message: Logged In: YES user_id=119770 Albert Chin-A-Young ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:00 Message: Logged In: YES user_id=6380 Closing. I applied the patch from "tww-china" in the CVS. (China, what's your real/full name, so we can add it to Misc/ACKS?) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-28 08:35 Message: Logged In: NO nevermind. i figured it out. muchas gracias. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-27 11:08 Message: Logged In: NO Sorry for my ignorance, but can someone tell me how to apply a python patch (or point me to the doc that explains how)? ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin-A- (tww-china) Date: 2001-09-26 10:20 Message: Logged In: YES user_id=119770 Oops. We accidentally deleted it. It's back now. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-26 09:58 Message: Logged In: NO Does anyone know where else this patch can be found? ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin-A- (tww-china) Date: 2001-06-14 03:47 Message: Logged In: YES user_id=119770 Try the patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-419062.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:14:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:14:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-419062 ] python 2.1 : building pbs on AIX 4.3.2 Message-ID: Bugs item #419062, was opened at 2001-04-25 23:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.1 : building pbs on AIX 4.3.2 Initial Comment: I met what could be called "regression"? problems : the "make all" process stopped at the beginning of the building of the shared modules under AIX 4.3.2. 1. it is looking for a "ld_so_aix" under the destination directory (${prefix}/lib/python2.1}) ... which, for an obvious reason is not there during the compiling phase 2. if you try to force the process by creating the directory and putting the "so needed" program in it, a new stop occurs : it is unable to find the "Python.exp" or whatever other *.exp file needed by the linking process Those problems didn't occur during the build of python 2.0 wich has been compiled fine under AIX 4.3.2 ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin-A- (tww-china) Date: 2001-09-28 09:14 Message: Logged In: YES user_id=119770 Not yet. I'll send a patch for #210665 tomorrow night. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:10 Message: Logged In: YES user_id=6380 Ah! You're already in our ACKS file. Thanks! (Any other patches of yours that you'd like us to have a look at?) ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin-A- (tww-china) Date: 2001-09-28 09:04 Message: Logged In: YES user_id=119770 Albert Chin-A-Young ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:00 Message: Logged In: YES user_id=6380 Closing. I applied the patch from "tww-china" in the CVS. (China, what's your real/full name, so we can add it to Misc/ACKS?) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-28 08:35 Message: Logged In: NO nevermind. i figured it out. muchas gracias. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-27 11:08 Message: Logged In: NO Sorry for my ignorance, but can someone tell me how to apply a python patch (or point me to the doc that explains how)? ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin-A- (tww-china) Date: 2001-09-26 10:20 Message: Logged In: YES user_id=119770 Oops. We accidentally deleted it. It's back now. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-26 09:58 Message: Logged In: NO Does anyone know where else this patch can be found? ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin-A- (tww-china) Date: 2001-06-14 03:47 Message: Logged In: YES user_id=119770 Try the patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-419062.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:15:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:15:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-452747 ] New-style class instances can't be copied Message-ID: Bugs item #452747, was opened at 2001-08-18 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Guido van Rossum (gvanrossum) >Summary: New-style class instances can't be copied Initial Comment: Any class which extends either the dictionary or list types in Python 2.2a1 is both unpickable by both the pickle module and cPickle, and is uncopyable by the copy module. Oh, and I'll use this opportunity to thank Guido and everyone who's ever worked on Python for making a programming language which is absolutely wonderful to program in. :) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:15 Message: Logged In: YES user_id=6380 This is mostly fixed in CVS and 2.2a4 (out today): you can pickle new-style classes now as long as they derive from picklable classes or from, and as long as they don't use __slots__. Issues: - copy module doesn't use copy_reg, so still can't copy these - object() can't be pickled; should it? - __slots__ not supported ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:35 Message: Logged In: YES user_id=6380 Thanks :-) Regarding your bug, it's more general than what you describe even: any class derived from object except certain built-in classes are unpicklable. I have to think about this -- part of my brain says that this is how it should be, and that you can register your constructor with copy_reg to make your type picklable, and another part of my brain says that it should be supported one way or another. Changed the subject to reflect the problem better. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:16:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:16:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-465447 ] os.makedirs can fail with UNC paths Message-ID: Bugs item #465447, was opened at 2001-09-26 17:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465447&group_id=5470 Category: Documentation Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.makedirs can fail with UNC paths Initial Comment: Calling os.makedirs('//remote/path/that/does/not/exist/yet') can cause an "OSError: [Errno 22] Invalid argument: '//remote'" If I map an equivalent network drive, it works fine (e.g. os.makedirs('N:/that/does/not/exist/yet')) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-28 09:16 Message: Logged In: YES user_id=3066 Added comments about UNC path non-support for os.makedirs() and the os.path module in Doc/lib/libos.tex revision 1.65 and Doc/lib/libposixpath.tex revision 1.20. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-27 09:19 Message: Logged In: YES user_id=31435 I agree. Most of these date back to DOS days, before UNC paths existed. The newer ones (like os.makedirs) appear to have been written with (only) Unix in mind. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 08:59 Message: Logged In: YES user_id=6380 I find that an unsettling conclusion. Maybe we've built too much knowledge about DOS paths into our path manipulation code? It's definitely a feature request, although in the short run it's OK to update the docs. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-26 20:07 Message: Logged In: YES user_id=31435 It's hard to know whether to call this a doc bug or a feature request -- it's something of both. Calling it a doc bug for now and reassigning to Fred. Lots of things don't work with UNC paths, starting with ntpath.split() (the immediate cause of the failure reported here). The only functions we have that understand UNC paths are path.splitunc(), and the only one that calls it, path.ismount() (which isn't called by anything else). Until someone contributes code and test cases to make everything else UNC-aware, we should document that sundry os. and os.path functions don't work with UNC paths correctly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465447&group_id=5470 From noreply@sourceforge.net Fri Sep 28 17:45:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 09:45:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-466125 ] PyLong_AsLongLong works for any integer Message-ID: Bugs item #466125, was opened at 2001-09-28 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_AsLongLong works for any integer Initial Comment: It would be nice if PyLong_AsLongLong worked more like PyInt_AsLong. When the value can be coerced into an integer, it should be. The current behavior is that PyLong_AsLongLong only works (without raising an exception) on instances of a PyLongObject. I would be far better for my application, http://www.llnl.gov/casc/components/, if PyLong_AsLongLong called PyInt_AsLong in cases where the argument is not a PyLongObject. The return value of PyInt_AsLong can safely be promoted to a long long. The end result that I would like is that an 'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long. PyArg_ParseTuple ultimately uses PyLong_AsLongLong to handle the L format code. It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1). Here is an example of how one might do this. This patch also changes the behavior of PyLong_AsLong to fall back on PyInt_AsLong. $ diff -c longobject.c~ longobject.c *** longobject.c~ Wed Jan 17 07:33:18 2001 --- longobject.c Fri Sep 28 09:42:45 2001 *************** *** 144,153 **** unsigned long x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; --- 144,156 ---- unsigned long x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); + } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; *************** *** 387,395 **** LONG_LONG x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; --- 390,401 ---- LONG_LONG x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; + } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); } v = (PyLongObject *)vv; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 From noreply@sourceforge.net Fri Sep 28 18:05:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 10:05:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-466125 ] PyLong_AsLongLong works for any integer Message-ID: Bugs item #466125, was opened at 2001-09-28 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Tom Epperly (tepperly) >Assigned to: Tim Peters (tim_one) Summary: PyLong_AsLongLong works for any integer Initial Comment: It would be nice if PyLong_AsLongLong worked more like PyInt_AsLong. When the value can be coerced into an integer, it should be. The current behavior is that PyLong_AsLongLong only works (without raising an exception) on instances of a PyLongObject. I would be far better for my application, http://www.llnl.gov/casc/components/, if PyLong_AsLongLong called PyInt_AsLong in cases where the argument is not a PyLongObject. The return value of PyInt_AsLong can safely be promoted to a long long. The end result that I would like is that an 'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long. PyArg_ParseTuple ultimately uses PyLong_AsLongLong to handle the L format code. It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1). Here is an example of how one might do this. This patch also changes the behavior of PyLong_AsLong to fall back on PyInt_AsLong. $ diff -c longobject.c~ longobject.c *** longobject.c~ Wed Jan 17 07:33:18 2001 --- longobject.c Fri Sep 28 09:42:45 2001 *************** *** 144,153 **** unsigned long x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; --- 144,156 ---- unsigned long x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); + } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; *************** *** 387,395 **** LONG_LONG x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; --- 390,401 ---- LONG_LONG x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; + } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); } v = (PyLongObject *)vv; ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 10:05 Message: Logged In: YES user_id=6380 Makes sense to me. Tim, what do you think? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 From noreply@sourceforge.net Fri Sep 28 19:59:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 11:59:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-452747 ] New-style class instances can't be copied Message-ID: Bugs item #452747, was opened at 2001-08-18 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Guido van Rossum (gvanrossum) Summary: New-style class instances can't be copied Initial Comment: Any class which extends either the dictionary or list types in Python 2.2a1 is both unpickable by both the pickle module and cPickle, and is uncopyable by the copy module. Oh, and I'll use this opportunity to thank Guido and everyone who's ever worked on Python for making a programming language which is absolutely wonderful to program in. :) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 11:59 Message: Logged In: YES user_id=6380 The first two of the remaining issues are fixed in CVS (but not in 2.2a4). I don't think it's worth supporting __slots__; classes with __slots__ should write their own __reduce__ method. Therefore, I'm closing this as "fixed". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 09:15 Message: Logged In: YES user_id=6380 This is mostly fixed in CVS and 2.2a4 (out today): you can pickle new-style classes now as long as they derive from picklable classes or from, and as long as they don't use __slots__. Issues: - copy module doesn't use copy_reg, so still can't copy these - object() can't be pickled; should it? - __slots__ not supported ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:35 Message: Logged In: YES user_id=6380 Thanks :-) Regarding your bug, it's more general than what you describe even: any class derived from object except certain built-in classes are unpicklable. I have to think about this -- part of my brain says that this is how it should be, and that you can register your constructor with copy_reg to make your type picklable, and another part of my brain says that it should be supported one way or another. Changed the subject to reflect the problem better. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470 From noreply@sourceforge.net Fri Sep 28 20:00:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 12:00:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-442734 ] 2.2a1: New style classes and pydoc Message-ID: Bugs item #442734, was opened at 2001-07-19 05:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442734&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter D�rwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and pydoc Initial Comment: pydoc (and the new builtin function help) don't find new style classes in modules: File test.py: ---- class foo: pass class bar(object): pass ---- Interactive session: >>> import test >>> help(test) Help on module test: NAME test FILE /data/home/walter/test.py CLASSES foo class foo DATA __file__ = 'test.py' __name__ = 'test' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 12:00 Message: Logged In: YES user_id=6380 This was taken care of by Tim. In 2.2a4, pydoc and inspect do a great job on new-style classes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 06:06 Message: Logged In: YES user_id=6380 Yup, inspect needs to be taught a lesson. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442734&group_id=5470 From noreply@sourceforge.net Fri Sep 28 20:47:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 12:47:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-466173 ] unpack TypeError unclear Message-ID: Bugs item #466173, was opened at 2001-09-28 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466173&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Tim Peters (tim_one) Summary: unpack TypeError unclear Initial Comment: I liked the error message in Python 2.1 better than the 2.2 error message for cases like this one: a, b = 1 It uses to say unpack non-sequence. Not is says iter() of non-sequence. Since the iter() call is hidden, I'd prefer to see it's specific error message hidden, too. To the user, it's just an error unpacking a sequeunce. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466173&group_id=5470 From noreply@sourceforge.net Fri Sep 28 20:52:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 12:52:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-466175 ] cPickle core dump Message-ID: Bugs item #466175, was opened at 2001-09-28 12:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466175&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 6 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: cPickle core dump Initial Comment: A cPickler Pickler() operating in fast mode, i.e. when Pickler().fast =1, dumps core on recursive objects. a = [] a.append(a) p = cPickle.Pickler() p.fast = 1 p.dump(a) [segfault] The fast flag indicates that pickle shouldn't keep track of object it has seen before, so it gets caught in an infinite loop if it hits a recursive object. Jim worries that fixing the segfault will slow down the fast mode, which is a big performance improvement. I think it can be solved using the same trick that we use for comparing and printing recursive objects like [[...]]. The approach is to use a simple counter to track recursive calls. Only track objects previously seen after the counter exceeds some threshhold. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466175&group_id=5470 From noreply@sourceforge.net Fri Sep 28 21:00:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 13:00:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-424002 ] sys.executable not reliable Message-ID: Bugs item #424002, was opened at 2001-05-14 11:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424002&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Evan Simpson (evansimpson) Assigned to: Guido van Rossum (gvanrossum) Summary: sys.executable not reliable Initial Comment: I created a file test.py containing: #!/usr/local/bin/python2.1 import sys print sys.executable When I run it using the command line "/usr/local/bin/python2.1 test.py", it prints the full path to the executable. When I run it from "/usr/local", using "bin/python2.1 test.py", then I get "bin/python2.1". When I run it using "./test.py", I get a blank string. Under version 1.5.2, all of these yielded the full path to the executable. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 13:00 Message: Logged In: YES user_id=6380 I think I've fixed this in CVS now (post-2.2a4). Can you test this with the new CVS? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:06 Message: Logged In: YES user_id=6380 Curious. I'll look into this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424002&group_id=5470 From noreply@sourceforge.net Fri Sep 28 21:03:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 13:03:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-466173 ] unpack TypeError unclear Message-ID: Bugs item #466173, was opened at 2001-09-28 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466173&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Tim Peters (tim_one) Summary: unpack TypeError unclear Initial Comment: I liked the error message in Python 2.1 better than the 2.2 error message for cases like this one: a, b = 1 It uses to say unpack non-sequence. Not is says iter() of non-sequence. Since the iter() call is hidden, I'd prefer to see it's specific error message hidden, too. To the user, it's just an error unpacking a sequeunce. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 13:03 Message: Logged In: YES user_id=6380 This has been discussed before. The iter() call doesn't know that it's called from a sequence unpack, so it's hard to get the old message back. As a compromise, I suggest to change the message not to refer to iter(), but to the more abstract concept of iteration, e.g. "iteration over non-sequence". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466173&group_id=5470 From noreply@sourceforge.net Fri Sep 28 21:04:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 13:04:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-466175 ] cPickle core dump Message-ID: Bugs item #466175, was opened at 2001-09-28 12:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466175&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 6 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: cPickle core dump Initial Comment: A cPickler Pickler() operating in fast mode, i.e. when Pickler().fast =1, dumps core on recursive objects. a = [] a.append(a) p = cPickle.Pickler() p.fast = 1 p.dump(a) [segfault] The fast flag indicates that pickle shouldn't keep track of object it has seen before, so it gets caught in an infinite loop if it hits a recursive object. Jim worries that fixing the segfault will slow down the fast mode, which is a big performance improvement. I think it can be solved using the same trick that we use for comparing and printing recursive objects like [[...]]. The approach is to use a simple counter to track recursive calls. Only track objects previously seen after the counter exceeds some threshhold. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 13:04 Message: Logged In: YES user_id=6380 Go for it. I take it this relates to a customer project? Else why the priority 6? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466175&group_id=5470 From noreply@sourceforge.net Fri Sep 28 22:05:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 14:05:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-466200 ] ability to specify a 'verify' script Message-ID: Bugs item #466200, was opened at 2001-09-28 14:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: A.M. Kuchling (akuchling) Summary: ability to specify a 'verify' script Initial Comment: The following patch adds the ability to specify a 'verify' script (as used by the %verify). Treatment is exactly the same as with post_install, etc... --- bdist_rpm.py Wed Sep 12 11:42:17 2001 +++ /home/agamemnon/jnelson/bdist_rpm.py Fri Sep 28 16:09:18 2001 @@ -131,6 +131,7 @@ self.post_install = None self.pre_uninstall = None self.post_uninstall = None + self.verifyscript = None self.prep = None self.provides = None self.requires = None @@ -210,6 +211,7 @@ self.ensure_filename('post_install') self.ensure_filename('pre_uninstall') self.ensure_filename('post_uninstall') + self.ensure_filename('verifyscript') # XXX don't forget we punted on summaries and descriptions -- they # should be handled here eventually! @@ -423,6 +425,7 @@ ('post', 'post_install', None), ('preun', 'pre_uninstall', None), ('postun', 'post_uninstall', None), + ('verify', 'verifyscript', None), ] for (rpm_opt, attr, default) in script_options: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 From noreply@sourceforge.net Fri Sep 28 22:21:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 14:21:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-465527 ] sqrt on a long int returns invalid resul Message-ID: Bugs item #465527, was opened at 2001-09-26 23:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465527&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Edward Kandrot (arcanelord) Assigned to: Tim Peters (tim_one) Summary: sqrt on a long int returns invalid resul Initial Comment: n = 1881988129206079638386972394616504398071635633794173827 0076335642298885971523466548531906060650474304531738801 1303396716199692321205734031879550656996221305168759307 650257059L x = long(math.sqrt(n)) the result of this is that x is off by many orders of magnitude. There should be a sqrt function that returns a long integer result so that large integer math will work as expected. I have written this function in python, one that would set x to be the integer part of a sqrt, but the hd it was on is currently damaged. If this is determined to be an actual problem that needs to be fixed, I will submit the code in this bug (unless someone beats me to it). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-28 14:21 Message: Logged In: YES user_id=31435 Well, a correct algorithm is more than a little subtle (floating division can't work here due to overflows, and if by "/" you're thinking "//" the algorithm is incorrect), and an *efficient* correct algorithm much more so. My own long-int integral-root code is both correct and quick, and is about 500(!) lines of Python (more than half in comment blocks sketching a correctness proof). Part of that was due to the inability to compute logs of longs quickly in 2.1, in order to get a good starting guess. I fixed that in 2.2, though, by generalizing math.log(long) and math.log10(long) to generate good log approximations for longs of any magnitude. The rest is that Newton steps approximately double the number of good bits on each iteration, and in the early iterations, when you've only got a few dozen good bits, computing the Newton steps with full long precision is a monstrous waste of time (when you've only got 12 good bits, (say) hundred-thousand bit arithmetic is factors of millions slower than necessary). So an efficient algorithm scales each step to use no more precision than is justified during that step. All of which is indeed an argument not to write it in C, though: the complex logic is much easier expressed in Python. The vast bulk of the runtime is consumed by division, and that's already in C (although GMP does long division much quickker than Python does it -- and probably always will). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 06:45 Message: Logged In: YES user_id=6380 Also, is the algorithm more than this? while abs(n-x*x) > 2*x+1: x = (x + n/x) / 2 I see no advantage to coding that in C, since all the time goes (presumably) into the arithmetic, which is already all in C. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-27 20:31 Message: Logged In: YES user_id=31435 I don't dispute that the function can be useful. That's not enough, though, and sqrt(2L) =- 1.414... is surely more useful to more people more often than sqrt(2L) == 1L. You should investigate the crypto work already done in Python, for example http://www.amk.ca/python/code/crypto.html There are also at least 2 Python wrappers for GMP, one hosted at SourceForge and another from Marc-Andre Lemburg. If you're doing serious crypto work, you certainly want GMP. If you're just putzing around, inventing long int algorithms on your own is seriously educational <0.9 wink>. ---------------------------------------------------------------------- Comment By: Edward Kandrot (arcanelord) Date: 2001-09-27 16:42 Message: Logged In: YES user_id=102159 Actually, this is a very useful function, since it is used in crytpography and other factoring-large-number projects. Without this function, I can not see how people would use python for this work, unless they did like I did, found out where the problem was, and write my own library for it. Everyone working on crypto using python will have to write their own sqrt, as it currently stands. I would recommend adding this to some library, maybe a large integer library could be made. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-27 13:48 Message: Logged In: YES user_id=31435 Closing as a Not-A-Bug, because it's functioning as designed. The math functions convert their arguments to C doubles, so you're never going to get more than 53 bits of precision of out them. >>> >>> sqrt(n) 4.338188710978442e+86 >>> To 53 signficant bits, that's an excellent approximation, and that's all the math.* functions can hope to deliver. Wholly accurate unbounded-int sqrt, pow etc are things Python doesn't have, and it's unclear whether it should (lots of code for a tiny audience). If that's wanted, I suggest that writing a PEP is in order first. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 13:43 Message: Logged In: YES user_id=6380 The math module does all its work in double precision floating point. I believe that the precision you are asking is unobtainable using floating point: x is much larger than the number of bits retained in the mantissa of a double precision number (53 I believe). So the best error bound on n-x*x that you can get is of the order of n/2**53. The value you get for n-x*x is significantly smaller than that, so I think the math module has done the best it can. ---------------------------------------------------------------------- Comment By: Edward Kandrot (arcanelord) Date: 2001-09-27 13:29 Message: Logged In: YES user_id=102159 I am using 2.1. I saw the problem on Linux previously, but I am on a Win2k box now with these results: >>> x 433818871097844195711080363479661366933416624844037360445918 708654950711556266965073920L >>> n-x*x 579455590187726959148083548468770884154260745498744050023793 649517960092688750631137087163290051389345006612268597554742 3732078994891141758379026196586090659L Since I do not have the program to give the correct answer, I can not tell you what it is right now (until I fix my Linux HD). I can tell you it is wrong by how much larger the remainder is from the sqrt. n-x*x should be less than 2*x+1, wereas the results from above is 133570858437146139501587560404236730965976658068588390668591 16036188472L*x+151281127770264061379550826654612638192882839 13990470767939415731499169681374054240419L (ie many magnitudes of order greater than expected). I will shortly recover the algorithm that calcs sqrt correctly and post it here, so at least we can see what I was expecting as a result. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 10:58 Message: Logged In: YES user_id=6380 Which Python version? On which platform? In 2.1 and 2.2 I get a decent result. Assigning to Tim who usually answers these questions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465527&group_id=5470 From noreply@sourceforge.net Fri Sep 28 22:50:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 14:50:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-465527 ] sqrt on a long int returns invalid resul Message-ID: Bugs item #465527, was opened at 2001-09-26 23:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465527&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Edward Kandrot (arcanelord) Assigned to: Tim Peters (tim_one) Summary: sqrt on a long int returns invalid resul Initial Comment: n = 1881988129206079638386972394616504398071635633794173827 0076335642298885971523466548531906060650474304531738801 1303396716199692321205734031879550656996221305168759307 650257059L x = long(math.sqrt(n)) the result of this is that x is off by many orders of magnitude. There should be a sqrt function that returns a long integer result so that large integer math will work as expected. I have written this function in python, one that would set x to be the integer part of a sqrt, but the hd it was on is currently damaged. If this is determined to be an actual problem that needs to be fixed, I will submit the code in this bug (unless someone beats me to it). ---------------------------------------------------------------------- >Comment By: Edward Kandrot (arcanelord) Date: 2001-09-28 14:50 Message: Logged In: YES user_id=102159 The algorithm I have was based off of a method I use to calc sqrts on paper, though I modified it to do 32 bits at a time (or the limit of floats) instead of one base10 digit. So, a 512 bit sqrt took 16 steps, with a few operations per step (I think the total code was 20-30 lines). I would be interested in the algorithm that you have, since I am always interested in performance. Could you please post it or email it to me? Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-28 14:21 Message: Logged In: YES user_id=31435 Well, a correct algorithm is more than a little subtle (floating division can't work here due to overflows, and if by "/" you're thinking "//" the algorithm is incorrect), and an *efficient* correct algorithm much more so. My own long-int integral-root code is both correct and quick, and is about 500(!) lines of Python (more than half in comment blocks sketching a correctness proof). Part of that was due to the inability to compute logs of longs quickly in 2.1, in order to get a good starting guess. I fixed that in 2.2, though, by generalizing math.log(long) and math.log10(long) to generate good log approximations for longs of any magnitude. The rest is that Newton steps approximately double the number of good bits on each iteration, and in the early iterations, when you've only got a few dozen good bits, computing the Newton steps with full long precision is a monstrous waste of time (when you've only got 12 good bits, (say) hundred-thousand bit arithmetic is factors of millions slower than necessary). So an efficient algorithm scales each step to use no more precision than is justified during that step. All of which is indeed an argument not to write it in C, though: the complex logic is much easier expressed in Python. The vast bulk of the runtime is consumed by division, and that's already in C (although GMP does long division much quickker than Python does it -- and probably always will). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 06:45 Message: Logged In: YES user_id=6380 Also, is the algorithm more than this? while abs(n-x*x) > 2*x+1: x = (x + n/x) / 2 I see no advantage to coding that in C, since all the time goes (presumably) into the arithmetic, which is already all in C. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-27 20:31 Message: Logged In: YES user_id=31435 I don't dispute that the function can be useful. That's not enough, though, and sqrt(2L) =- 1.414... is surely more useful to more people more often than sqrt(2L) == 1L. You should investigate the crypto work already done in Python, for example http://www.amk.ca/python/code/crypto.html There are also at least 2 Python wrappers for GMP, one hosted at SourceForge and another from Marc-Andre Lemburg. If you're doing serious crypto work, you certainly want GMP. If you're just putzing around, inventing long int algorithms on your own is seriously educational <0.9 wink>. ---------------------------------------------------------------------- Comment By: Edward Kandrot (arcanelord) Date: 2001-09-27 16:42 Message: Logged In: YES user_id=102159 Actually, this is a very useful function, since it is used in crytpography and other factoring-large-number projects. Without this function, I can not see how people would use python for this work, unless they did like I did, found out where the problem was, and write my own library for it. Everyone working on crypto using python will have to write their own sqrt, as it currently stands. I would recommend adding this to some library, maybe a large integer library could be made. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-27 13:48 Message: Logged In: YES user_id=31435 Closing as a Not-A-Bug, because it's functioning as designed. The math functions convert their arguments to C doubles, so you're never going to get more than 53 bits of precision of out them. >>> >>> sqrt(n) 4.338188710978442e+86 >>> To 53 signficant bits, that's an excellent approximation, and that's all the math.* functions can hope to deliver. Wholly accurate unbounded-int sqrt, pow etc are things Python doesn't have, and it's unclear whether it should (lots of code for a tiny audience). If that's wanted, I suggest that writing a PEP is in order first. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 13:43 Message: Logged In: YES user_id=6380 The math module does all its work in double precision floating point. I believe that the precision you are asking is unobtainable using floating point: x is much larger than the number of bits retained in the mantissa of a double precision number (53 I believe). So the best error bound on n-x*x that you can get is of the order of n/2**53. The value you get for n-x*x is significantly smaller than that, so I think the math module has done the best it can. ---------------------------------------------------------------------- Comment By: Edward Kandrot (arcanelord) Date: 2001-09-27 13:29 Message: Logged In: YES user_id=102159 I am using 2.1. I saw the problem on Linux previously, but I am on a Win2k box now with these results: >>> x 433818871097844195711080363479661366933416624844037360445918 708654950711556266965073920L >>> n-x*x 579455590187726959148083548468770884154260745498744050023793 649517960092688750631137087163290051389345006612268597554742 3732078994891141758379026196586090659L Since I do not have the program to give the correct answer, I can not tell you what it is right now (until I fix my Linux HD). I can tell you it is wrong by how much larger the remainder is from the sqrt. n-x*x should be less than 2*x+1, wereas the results from above is 133570858437146139501587560404236730965976658068588390668591 16036188472L*x+151281127770264061379550826654612638192882839 13990470767939415731499169681374054240419L (ie many magnitudes of order greater than expected). I will shortly recover the algorithm that calcs sqrt correctly and post it here, so at least we can see what I was expecting as a result. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 10:58 Message: Logged In: YES user_id=6380 Which Python version? On which platform? In 2.1 and 2.2 I get a decent result. Assigning to Tim who usually answers these questions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465527&group_id=5470 From noreply@sourceforge.net Fri Sep 28 23:07:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 15:07:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-466175 ] cPickle core dump Message-ID: Bugs item #466175, was opened at 2001-09-28 12:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466175&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 6 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: cPickle core dump Initial Comment: A cPickler Pickler() operating in fast mode, i.e. when Pickler().fast =1, dumps core on recursive objects. a = [] a.append(a) p = cPickle.Pickler() p.fast = 1 p.dump(a) [segfault] The fast flag indicates that pickle shouldn't keep track of object it has seen before, so it gets caught in an infinite loop if it hits a recursive object. Jim worries that fixing the segfault will slow down the fast mode, which is a big performance improvement. I think it can be solved using the same trick that we use for comparing and printing recursive objects like [[...]]. The approach is to use a simple counter to track recursive calls. Only track objects previously seen after the counter exceeds some threshhold. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-09-28 15:07 Message: Logged In: YES user_id=31392 No customer project. It's higher than 5 because it's a core dump rather than merely incorrect behavior. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 13:04 Message: Logged In: YES user_id=6380 Go for it. I take it this relates to a customer project? Else why the priority 6? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466175&group_id=5470 From noreply@sourceforge.net Sat Sep 29 01:28:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Sep 2001 17:28:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-465527 ] sqrt on a long int returns invalid resul Message-ID: Bugs item #465527, was opened at 2001-09-26 23:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465527&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Edward Kandrot (arcanelord) Assigned to: Tim Peters (tim_one) Summary: sqrt on a long int returns invalid resul Initial Comment: n = 1881988129206079638386972394616504398071635633794173827 0076335642298885971523466548531906060650474304531738801 1303396716199692321205734031879550656996221305168759307 650257059L x = long(math.sqrt(n)) the result of this is that x is off by many orders of magnitude. There should be a sqrt function that returns a long integer result so that large integer math will work as expected. I have written this function in python, one that would set x to be the integer part of a sqrt, but the hd it was on is currently damaged. If this is determined to be an actual problem that needs to be fixed, I will submit the code in this bug (unless someone beats me to it). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-28 17:28 Message: Logged In: YES user_id=31435 Sorry, I can't afford to get sucked into a detailed discussion of this, and sharing the code anywhere would just lead to more time drain. The heart of it is this, a correct version of Guido's stab: def longroot(n, r, g): . """Return floor(n**(1./r)), as if it infinite precision. . g must be a starting guess such that g**r > n. . """ . assert n > 0 . assert r > 1 . assert g**r > n . while 1: . delta = (n/g**(r-1) - g) / r . if delta < 0: . g += delta . else: . break . assert g**r <= n < (g+1)**r . return g Proving correctness, generating a good starting guess, optimizing to use fewer bits in early iterations, performance analysis, and specializing to r=2 are all left as exercises (some difficult). Again, if you're serious about crypto research, get one of the Python GMP wrappers. GMP has hyper-optimized bigint root extraction functions, faster than anything you're going to come up with on your own, and faster than Python will ever have (not that it has any ). ---------------------------------------------------------------------- Comment By: Edward Kandrot (arcanelord) Date: 2001-09-28 14:50 Message: Logged In: YES user_id=102159 The algorithm I have was based off of a method I use to calc sqrts on paper, though I modified it to do 32 bits at a time (or the limit of floats) instead of one base10 digit. So, a 512 bit sqrt took 16 steps, with a few operations per step (I think the total code was 20-30 lines). I would be interested in the algorithm that you have, since I am always interested in performance. Could you please post it or email it to me? Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-28 14:21 Message: Logged In: YES user_id=31435 Well, a correct algorithm is more than a little subtle (floating division can't work here due to overflows, and if by "/" you're thinking "//" the algorithm is incorrect), and an *efficient* correct algorithm much more so. My own long-int integral-root code is both correct and quick, and is about 500(!) lines of Python (more than half in comment blocks sketching a correctness proof). Part of that was due to the inability to compute logs of longs quickly in 2.1, in order to get a good starting guess. I fixed that in 2.2, though, by generalizing math.log(long) and math.log10(long) to generate good log approximations for longs of any magnitude. The rest is that Newton steps approximately double the number of good bits on each iteration, and in the early iterations, when you've only got a few dozen good bits, computing the Newton steps with full long precision is a monstrous waste of time (when you've only got 12 good bits, (say) hundred-thousand bit arithmetic is factors of millions slower than necessary). So an efficient algorithm scales each step to use no more precision than is justified during that step. All of which is indeed an argument not to write it in C, though: the complex logic is much easier expressed in Python. The vast bulk of the runtime is consumed by division, and that's already in C (although GMP does long division much quickker than Python does it -- and probably always will). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 06:45 Message: Logged In: YES user_id=6380 Also, is the algorithm more than this? while abs(n-x*x) > 2*x+1: x = (x + n/x) / 2 I see no advantage to coding that in C, since all the time goes (presumably) into the arithmetic, which is already all in C. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-27 20:31 Message: Logged In: YES user_id=31435 I don't dispute that the function can be useful. That's not enough, though, and sqrt(2L) =- 1.414... is surely more useful to more people more often than sqrt(2L) == 1L. You should investigate the crypto work already done in Python, for example http://www.amk.ca/python/code/crypto.html There are also at least 2 Python wrappers for GMP, one hosted at SourceForge and another from Marc-Andre Lemburg. If you're doing serious crypto work, you certainly want GMP. If you're just putzing around, inventing long int algorithms on your own is seriously educational <0.9 wink>. ---------------------------------------------------------------------- Comment By: Edward Kandrot (arcanelord) Date: 2001-09-27 16:42 Message: Logged In: YES user_id=102159 Actually, this is a very useful function, since it is used in crytpography and other factoring-large-number projects. Without this function, I can not see how people would use python for this work, unless they did like I did, found out where the problem was, and write my own library for it. Everyone working on crypto using python will have to write their own sqrt, as it currently stands. I would recommend adding this to some library, maybe a large integer library could be made. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-27 13:48 Message: Logged In: YES user_id=31435 Closing as a Not-A-Bug, because it's functioning as designed. The math functions convert their arguments to C doubles, so you're never going to get more than 53 bits of precision of out them. >>> >>> sqrt(n) 4.338188710978442e+86 >>> To 53 signficant bits, that's an excellent approximation, and that's all the math.* functions can hope to deliver. Wholly accurate unbounded-int sqrt, pow etc are things Python doesn't have, and it's unclear whether it should (lots of code for a tiny audience). If that's wanted, I suggest that writing a PEP is in order first. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 13:43 Message: Logged In: YES user_id=6380 The math module does all its work in double precision floating point. I believe that the precision you are asking is unobtainable using floating point: x is much larger than the number of bits retained in the mantissa of a double precision number (53 I believe). So the best error bound on n-x*x that you can get is of the order of n/2**53. The value you get for n-x*x is significantly smaller than that, so I think the math module has done the best it can. ---------------------------------------------------------------------- Comment By: Edward Kandrot (arcanelord) Date: 2001-09-27 13:29 Message: Logged In: YES user_id=102159 I am using 2.1. I saw the problem on Linux previously, but I am on a Win2k box now with these results: >>> x 433818871097844195711080363479661366933416624844037360445918 708654950711556266965073920L >>> n-x*x 579455590187726959148083548468770884154260745498744050023793 649517960092688750631137087163290051389345006612268597554742 3732078994891141758379026196586090659L Since I do not have the program to give the correct answer, I can not tell you what it is right now (until I fix my Linux HD). I can tell you it is wrong by how much larger the remainder is from the sqrt. n-x*x should be less than 2*x+1, wereas the results from above is 133570858437146139501587560404236730965976658068588390668591 16036188472L*x+151281127770264061379550826654612638192882839 13990470767939415731499169681374054240419L (ie many magnitudes of order greater than expected). I will shortly recover the algorithm that calcs sqrt correctly and post it here, so at least we can see what I was expecting as a result. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 10:58 Message: Logged In: YES user_id=6380 Which Python version? On which platform? In 2.1 and 2.2 I get a decent result. Assigning to Tim who usually answers these questions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465527&group_id=5470 From noreply@sourceforge.net Sun Sep 30 05:20:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Sep 2001 21:20:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-466125 ] PyLong_AsLongLong works for any integer Message-ID: Bugs item #466125, was opened at 2001-09-28 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Tim Peters (tim_one) Summary: PyLong_AsLongLong works for any integer Initial Comment: It would be nice if PyLong_AsLongLong worked more like PyInt_AsLong. When the value can be coerced into an integer, it should be. The current behavior is that PyLong_AsLongLong only works (without raising an exception) on instances of a PyLongObject. I would be far better for my application, http://www.llnl.gov/casc/components/, if PyLong_AsLongLong called PyInt_AsLong in cases where the argument is not a PyLongObject. The return value of PyInt_AsLong can safely be promoted to a long long. The end result that I would like is that an 'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long. PyArg_ParseTuple ultimately uses PyLong_AsLongLong to handle the L format code. It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1). Here is an example of how one might do this. This patch also changes the behavior of PyLong_AsLong to fall back on PyInt_AsLong. $ diff -c longobject.c~ longobject.c *** longobject.c~ Wed Jan 17 07:33:18 2001 --- longobject.c Fri Sep 28 09:42:45 2001 *************** *** 144,153 **** unsigned long x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; --- 144,156 ---- unsigned long x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); + } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; *************** *** 387,395 **** LONG_LONG x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; --- 390,401 ---- LONG_LONG x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; + } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); } v = (PyLongObject *)vv; ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-29 21:20 Message: Logged In: YES user_id=31435 Hmm. The patch is against some older version of Python that doesn't bear much textual resemblance to current longobject.c (i.e., patch can't make head or tail of this). I believe Guido already changed PyLong_AsLong(), about 2 weeks ago, to back off to PyInt_AsLong if an int object is passed in. PyLong_AsLongLong() does not, though, and I agree it's a good idea. So I'll do that. Tom, I hope you didn't intend your "It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1)" to have more actual content than "It would be nice if people never died before they were ready to go" <0.9 wink>. But if so, we obviously can't change the behavior of code that's already been released. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 10:05 Message: Logged In: YES user_id=6380 Makes sense to me. Tim, what do you think? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 From noreply@sourceforge.net Sun Sep 30 05:36:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Sep 2001 21:36:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-466125 ] PyLong_AsLongLong works for any integer Message-ID: Bugs item #466125, was opened at 2001-09-28 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Tim Peters (tim_one) Summary: PyLong_AsLongLong works for any integer Initial Comment: It would be nice if PyLong_AsLongLong worked more like PyInt_AsLong. When the value can be coerced into an integer, it should be. The current behavior is that PyLong_AsLongLong only works (without raising an exception) on instances of a PyLongObject. I would be far better for my application, http://www.llnl.gov/casc/components/, if PyLong_AsLongLong called PyInt_AsLong in cases where the argument is not a PyLongObject. The return value of PyInt_AsLong can safely be promoted to a long long. The end result that I would like is that an 'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long. PyArg_ParseTuple ultimately uses PyLong_AsLongLong to handle the L format code. It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1). Here is an example of how one might do this. This patch also changes the behavior of PyLong_AsLong to fall back on PyInt_AsLong. $ diff -c longobject.c~ longobject.c *** longobject.c~ Wed Jan 17 07:33:18 2001 --- longobject.c Fri Sep 28 09:42:45 2001 *************** *** 144,153 **** unsigned long x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; --- 144,156 ---- unsigned long x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); + } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; *************** *** 387,395 **** LONG_LONG x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; --- 390,401 ---- LONG_LONG x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; + } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); } v = (PyLongObject *)vv; ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-29 21:36 Message: Logged In: YES user_id=31435 Oops! What Guido did in PyLong_AsLong is back off to PyInt_AsLong but only if PyInt_Check is true. What the suggested patch does is call PyInt_AsLong in *any* non-NULL case where PyLong_Check is false, and that includes dubious things like converting floats to ints. I don't think we want that, and it isn't needed for your stated goal ("'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long"). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-29 21:20 Message: Logged In: YES user_id=31435 Hmm. The patch is against some older version of Python that doesn't bear much textual resemblance to current longobject.c (i.e., patch can't make head or tail of this). I believe Guido already changed PyLong_AsLong(), about 2 weeks ago, to back off to PyInt_AsLong if an int object is passed in. PyLong_AsLongLong() does not, though, and I agree it's a good idea. So I'll do that. Tom, I hope you didn't intend your "It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1)" to have more actual content than "It would be nice if people never died before they were ready to go" <0.9 wink>. But if so, we obviously can't change the behavior of code that's already been released. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 10:05 Message: Logged In: YES user_id=6380 Makes sense to me. Tim, what do you think? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 From noreply@sourceforge.net Sun Sep 30 06:12:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Sep 2001 22:12:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-466125 ] PyLong_AsLongLong works for any integer Message-ID: Bugs item #466125, was opened at 2001-09-28 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Tim Peters (tim_one) Summary: PyLong_AsLongLong works for any integer Initial Comment: It would be nice if PyLong_AsLongLong worked more like PyInt_AsLong. When the value can be coerced into an integer, it should be. The current behavior is that PyLong_AsLongLong only works (without raising an exception) on instances of a PyLongObject. I would be far better for my application, http://www.llnl.gov/casc/components/, if PyLong_AsLongLong called PyInt_AsLong in cases where the argument is not a PyLongObject. The return value of PyInt_AsLong can safely be promoted to a long long. The end result that I would like is that an 'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long. PyArg_ParseTuple ultimately uses PyLong_AsLongLong to handle the L format code. It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1). Here is an example of how one might do this. This patch also changes the behavior of PyLong_AsLong to fall back on PyInt_AsLong. $ diff -c longobject.c~ longobject.c *** longobject.c~ Wed Jan 17 07:33:18 2001 --- longobject.c Fri Sep 28 09:42:45 2001 *************** *** 144,153 **** unsigned long x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; --- 144,156 ---- unsigned long x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); + } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; *************** *** 387,395 **** LONG_LONG x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; --- 390,401 ---- LONG_LONG x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; + } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); } v = (PyLongObject *)vv; ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-29 22:12 Message: Logged In: YES user_id=31435 PyLong_AsLongLong (and so also PyArg_ParseTuple 'L') now accepts longs and ints (but not types other than those and subclasses of those), for 2.2: Doc/ext/extending.tex; new revision: 1.3 Misc/ACKS; new revision: 1.113 Misc/NEWS; new revision: 1.260 Modules/_testcapimodule.c; new revision: 1.12 Objects/longobject.c; new revision: 1.110 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-29 21:36 Message: Logged In: YES user_id=31435 Oops! What Guido did in PyLong_AsLong is back off to PyInt_AsLong but only if PyInt_Check is true. What the suggested patch does is call PyInt_AsLong in *any* non-NULL case where PyLong_Check is false, and that includes dubious things like converting floats to ints. I don't think we want that, and it isn't needed for your stated goal ("'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long"). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-29 21:20 Message: Logged In: YES user_id=31435 Hmm. The patch is against some older version of Python that doesn't bear much textual resemblance to current longobject.c (i.e., patch can't make head or tail of this). I believe Guido already changed PyLong_AsLong(), about 2 weeks ago, to back off to PyInt_AsLong if an int object is passed in. PyLong_AsLongLong() does not, though, and I agree it's a good idea. So I'll do that. Tom, I hope you didn't intend your "It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1)" to have more actual content than "It would be nice if people never died before they were ready to go" <0.9 wink>. But if so, we obviously can't change the behavior of code that's already been released. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 10:05 Message: Logged In: YES user_id=6380 Makes sense to me. Tim, what do you think? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 From noreply@sourceforge.net Sun Sep 30 06:59:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Sep 2001 22:59:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-466173 ] unpack TypeError unclear Message-ID: Bugs item #466173, was opened at 2001-09-28 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466173&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Tim Peters (tim_one) Summary: unpack TypeError unclear Initial Comment: I liked the error message in Python 2.1 better than the 2.2 error message for cases like this one: a, b = 1 It uses to say unpack non-sequence. Not is says iter() of non-sequence. Since the iter() call is hidden, I'd prefer to see it's specific error message hidden, too. To the user, it's just an error unpacking a sequeunce. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-29 22:59 Message: Logged In: YES user_id=31435 I did both: replaced the 3 generic msgs as Guido suggested, and restored the specific msg Jeremy suggested. Objects/abstract.c; new revision: 2.82 Objects/classobject.c; new revision: 2.151 Objects/typeobject.c; new revision: 2.78 Python/ceval.c; new revision: 2.279 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 13:03 Message: Logged In: YES user_id=6380 This has been discussed before. The iter() call doesn't know that it's called from a sequence unpack, so it's hard to get the old message back. As a compromise, I suggest to change the message not to refer to iter(), but to the more abstract concept of iteration, e.g. "iteration over non-sequence". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466173&group_id=5470 From noreply@sourceforge.net Sun Sep 30 19:28:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Sep 2001 11:28:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-466125 ] PyLong_AsLongLong works for any integer Message-ID: Bugs item #466125, was opened at 2001-09-28 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Tim Peters (tim_one) Summary: PyLong_AsLongLong works for any integer Initial Comment: It would be nice if PyLong_AsLongLong worked more like PyInt_AsLong. When the value can be coerced into an integer, it should be. The current behavior is that PyLong_AsLongLong only works (without raising an exception) on instances of a PyLongObject. I would be far better for my application, http://www.llnl.gov/casc/components/, if PyLong_AsLongLong called PyInt_AsLong in cases where the argument is not a PyLongObject. The return value of PyInt_AsLong can safely be promoted to a long long. The end result that I would like is that an 'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long. PyArg_ParseTuple ultimately uses PyLong_AsLongLong to handle the L format code. It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1). Here is an example of how one might do this. This patch also changes the behavior of PyLong_AsLong to fall back on PyInt_AsLong. $ diff -c longobject.c~ longobject.c *** longobject.c~ Wed Jan 17 07:33:18 2001 --- longobject.c Fri Sep 28 09:42:45 2001 *************** *** 144,153 **** unsigned long x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; --- 144,156 ---- unsigned long x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); + } v = (PyLongObject *)vv; i = v->ob_size; sign = 1; *************** *** 387,395 **** LONG_LONG x, prev; int i, sign; ! if (vv == NULL || !PyLong_Check(vv)) { PyErr_BadInternalCall(); return -1; } v = (PyLongObject *)vv; --- 390,401 ---- LONG_LONG x, prev; int i, sign; ! if (vv == NULL) { PyErr_BadInternalCall(); return -1; + } + if (!PyLong_Check(vv)) { + return PyInt_AsLong(vv); } v = (PyLongObject *)vv; ---------------------------------------------------------------------- >Comment By: Tom Epperly (tepperly) Date: 2001-09-30 11:28 Message: Logged In: YES user_id=94539 Thanks to all for making the change. It will make my Python language bindings easier and better. When I spoke of changing it in past version, I did not mean to suggest time travel or some method of altering everyone's installations of previously released version. I was wondering if it could be included in future bug fix releases to previously released versions. However, this appears to be against your policy for bug fixes that I've gleaned from your WWW pages. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-29 22:12 Message: Logged In: YES user_id=31435 PyLong_AsLongLong (and so also PyArg_ParseTuple 'L') now accepts longs and ints (but not types other than those and subclasses of those), for 2.2: Doc/ext/extending.tex; new revision: 1.3 Misc/ACKS; new revision: 1.113 Misc/NEWS; new revision: 1.260 Modules/_testcapimodule.c; new revision: 1.12 Objects/longobject.c; new revision: 1.110 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-29 21:36 Message: Logged In: YES user_id=31435 Oops! What Guido did in PyLong_AsLong is back off to PyInt_AsLong but only if PyInt_Check is true. What the suggested patch does is call PyInt_AsLong in *any* non-NULL case where PyLong_Check is false, and that includes dubious things like converting floats to ints. I don't think we want that, and it isn't needed for your stated goal ("'L' in a PyArg_ParseTuple call return any integer value (int or long) as a C long long"). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-29 21:20 Message: Logged In: YES user_id=31435 Hmm. The patch is against some older version of Python that doesn't bear much textual resemblance to current longobject.c (i.e., patch can't make head or tail of this). I believe Guido already changed PyLong_AsLong(), about 2 weeks ago, to back off to PyInt_AsLong if an int object is passed in. PyLong_AsLongLong() does not, though, and I agree it's a good idea. So I'll do that. Tom, I hope you didn't intend your "It would be nice to have this behavior in past versions too (i.e. 1.5.2, 2.0 and 2.1)" to have more actual content than "It would be nice if people never died before they were ready to go" <0.9 wink>. But if so, we obviously can't change the behavior of code that's already been released. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 10:05 Message: Logged In: YES user_id=6380 Makes sense to me. Tim, what do you think? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466125&group_id=5470 From noreply@sourceforge.net Sun Sep 30 21:35:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Sep 2001 13:35:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-463996 ] quopri RFC 2047 and hex 20 encodings Message-ID: Bugs item #463996, was opened at 2001-09-22 19:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=463996&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: quopri RFC 2047 and hex 20 encodings Initial Comment: In RFC 2047, the quoted-printable (i.e. "Q") encoding allows for _ to encode hex 20. See section 4.2 of that RFC. However, quopri was written against RFC 1521 which doesn't describe hex20/underscore encoding. quopri should be updated to allow for decoding of underscore to hex 20, perhaps as a flag on the decode() and decodestring() functions. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2001-09-30 13:35 Message: Logged In: YES user_id=21627 I believe this bug has been fixed with patch #462190, which has been committed. If there are still open issues left, please indicate what they are, and we'll re-open the report. ---------------------------------------------------------------------- Comment By: Kent Engstr�m (kente) Date: 2001-09-23 07:04 Message: Logged In: YES user_id=178855 See patch 464070 for a minimal decode enhancement. ---------------------------------------------------------------------- Comment By: Kent Engstr�m (kente) Date: 2001-09-23 04:24 Message: Logged In: YES user_id=178855 We should not directly compare RFC 2047 and RFC 1521. RFC 1521 = Old standard, "QP for bodies" RFC 1522 = Old standard, "QP for headers" RFC 2045 = New standard, "QP for bodies" RFC 2027 = New standard, "QP for headers" The "underscore coding" is present already in RFC 1522, and absent in RFC 2045. A flag sent to the relevant functions may be the right way, but we want it to be something like "header_style", not "new_style". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=463996&group_id=5470 From noreply@sourceforge.net Sun Sep 30 22:43:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Sep 2001 14:43:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-465467 ] os.unsetenv not implemented Message-ID: Bugs item #465467, was opened at 2001-09-26 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465467&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Naris Siamwalla (naris) Assigned to: Nobody/Anonymous (nobody) Summary: os.unsetenv not implemented Initial Comment: if os.putenv is implemented, os.unsetenv should be, too. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2001-09-30 14:43 Message: Logged In: YES user_id=21627 A patch for this bug is under development in http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=460805 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465467&group_id=5470