From teresa@saintmail.net Sun Apr 2 19:26:41 2000 From: teresa@saintmail.net (teresa@saintmail.net) Date: Sun, 2 Apr 2000 14:26:41 -0400 (EDT) Subject: [Python-bugs-list] Looking For Financial Freedom? (PR#261) Message-ID: <20000402182641.AB8081CDA7@dinsdale.python.org> FOLLOW ME TO FINANCIAL FREEDOM!! 1-888-217-0292 CALL NOW!! see below for remove. I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET-RICH-QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! ABOUT MAKING MONEY!!! CALL NOW 1-888-217-0292 DON'T GO TO SLEEP WITHOUT LISTENING TO THIS! "All our dreams can come true - if we have the courage to pursue them" -Walt Disney Please leave your name and number and best time to call. DO NOT respond by Email. We are trttibly sorry if you have received this message in error. If you wish to be removed. Please, type "REMOVE"in the subject line. frice@beijingoffice.com From rosa16@pplmail.com Sun Apr 2 19:29:51 2000 From: rosa16@pplmail.com (rosa16@pplmail.com) Date: Sun, 2 Apr 2000 14:29:51 -0400 (EDT) Subject: [Python-bugs-list] Looking For Financial Freedom? (PR#262) Message-ID: <20000402182951.03A711CDA7@dinsdale.python.org> FOLLOW ME TO FINANCIAL FREEDOM!! 1-888-217-0292 CALL NOW!! see below for remove. I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET-RICH-QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! ABOUT MAKING MONEY!!! CALL NOW 1-888-217-0292 DON'T GO TO SLEEP WITHOUT LISTENING TO THIS! "All our dreams can come true - if we have the courage to pursue them" -Walt Disney Please leave your name and number and best time to call. DO NOT respond by Email. We are trttibly sorry if you have received this message in error. If you wish to be removed. Please, type "REMOVE"in the subject line. frice@beijingoffice.com From pinard@iro.umontreal.ca Sun Apr 2 21:57:13 2000 From: pinard@iro.umontreal.ca (pinard@iro.umontreal.ca) Date: Sun, 2 Apr 2000 16:57:13 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000402205713.5F9041CDD6@dinsdale.python.org> Hello. This is an installation report for Python 1.6a1 on a SuSE 6.2 Linux system, using a 2.2.10 kernel, gcc 2.7.2 and GNU libc 2.1.1. I used http://sunsite.doc.ic.ac.uk/Mirrors/ftp.python.org/pub/www.python.org to get the distribution, as www.python.org was rejecting contact requests. The system I use is usually not Internet-connected (this complicates the uploads a bit :-), and so, I will not be able to take advantage of the nice module dynamic upload facilities that were described on Aprit 1st! :-) Python was configured using no special configuration switches, and configuration seemingly completed without problems. Compilation yielded a single diagnostic: -----> make[1]: Entre dans le répertoire `/var/tmp/python-1.6a1/Modules' ./timemodule.c: In function `time_strptime': ./timemodule.c:428: warning: assignment makes pointer from integer without a cast -----< The `make install' command, which was: -----> make -f Makefile prefix=/usr/local/stow/python-1.6a1 exec_prefix=/usr/local/stow/python-1.6a1 install -----< raised that difficulty: -----> Creating directory /usr/local/stow/python-1.6a1/bin mkdir: Ne peut créer le répertoire `/usr/local/stow/python-1.6a1/bin'.: No such file or directory -----< Creating `/usr/local/stow/python-1.6a1' by hand and reinstalling allowed Python to get in its place, yet for all Autoconf-igured packages I installed here, this is not necessary so far that I remember. Maybe Python does not use `mkinstalldirs' (I did not check)? If not, it should do similarly. Auto-compilation of installed Python sources (I presume that the installation is careful to use its own Python), yielded a few warnings and errors, listed below: -----> [...] Compiling /usr/local/stow/python-1.6a1/lib/python1.6/asynchat.py ... Tab size set to 4 Compiling /usr/local/stow/python-1.6a1/lib/python1.6/asyncore.py ... Tab size set to 4 [...] Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre.py ... Tab size set to 4 File "/usr/local/stow/python-1.6a1/lib/python1.6/sre.py", line 17 ^ SyntaxError: invalid syntax Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_compile.py ... File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_compile.py", line 16 ^ SyntaxError: invalid syntax Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_constants.py ... File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_constants.py", line 17 ^ SyntaxError: invalid syntax Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_parse.py ... File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_parse.py", line 18 ^ SyntaxError: invalid syntax [...] Compiling /usr/local/stow/python-1.6a1/lib/python1.6/test/test_pyexpat.py ... : inconsistent tab/space usage -----< And then, it seems the whole compilation is launched once more through: -----> PYTHONPATH=/usr/local/stow/python-1.6a1/lib/python1.6 \ ./python -O /usr/local/stow/python-1.6a1/lib/python1.6/compileall.py /usr/local/stow/python-1.6a1/lib/python1.6 -----< yielding the same set errors for a second time. -- François Pinard http://www.iro.umontreal.ca/~pinard From pinard@iro.umontreal.ca Sun Apr 2 22:22:24 2000 From: pinard@iro.umontreal.ca (pinard@iro.umontreal.ca) Date: Sun, 2 Apr 2000 17:22:24 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) Message-ID: <20000402212224.38C5B1CDB2@dinsdale.python.org> Hello. This is for the Python 1.6a1 release. File `Misc/python-mode.el' still has the problem that a region, part of a some bigger structure, may not be fed to the interpreter unless it is left-justified first. It is cumbersome having to explicitly left-justify a region for sending it, every time, and then undoing the left-justification back in its normal place once sent. I sent the following patch was sent to the Python mailing list, a while ago, to automate this. I was expecting it, or any similar functionality, to be integrated by now. So, here it is again. --- ./python-mode.el Tue Aug 10 17:49:00 1999 +++ /bpi/titan/home/pinard/el/python-mode.el Tue Feb 22 14:35:02 2000 @@ -1278,11 +1278,34 @@ (format "python-%d-%d" sn pid) (format "python-%d" sn))) (make-temp-name "python-"))) - (file (expand-file-name temp py-temp-directory))) - (write-region start end file nil 'nomsg) + (file (expand-file-name temp py-temp-directory)) + input) + (save-excursion + (let ((margin -1)) + (goto-char start) + (while (and (not (zerop margin)) (< (point) end)) + (skip-chars-forward " \t") + (let ((column (current-column))) + (and (not (= (following-char) ?\n)) + (or (< margin 0) (< column margin)) + (setq margin column))) + (forward-line 1)) + (if (> margin 0) + (let ((buffer (current-buffer))) + (setq input (get-buffer-create + (generate-new-buffer-name " *Python Input*"))) + (set-buffer input) + (insert-buffer-substring buffer start end) + (indent-rigidly (point-min) (point-max) (- margin)))))) (cond ;; always run the code in its own asynchronous subprocess (async + (if (not input) + (write-region start end file nil 'nomsg) + (save-excursion + (set-buffer input) + (write-region (point-min) (point-max) file nil 'nomsg)) + (kill-buffer input)) (let* ((buf (generate-new-buffer-name py-output-buffer)) ;; TBD: a horrible hack, but why create new Custom variables? (arg (if (string-equal py-which-bufname "Python") @@ -1295,18 +1318,30 @@ ;; execution there. (proc ;; use the existing python shell + (if (not input) + (write-region start end file nil 'nomsg) + (save-excursion + (set-buffer input) + (write-region (point-min) (point-max) file nil 'nomsg)) + (kill-buffer input)) (if (not py-file-queue) (py-execute-file proc file) (message "File %s queued for execution" file)) (setq py-file-queue (append py-file-queue (list file))) (setq py-exception-buffer (cons file (current-buffer)))) (t - ;; TBD: a horrible hack, buy why create new Custom variables? + ;; TBD: a horrible hack, but why create new Custom variables? (let ((cmd (concat py-which-shell (if (string-equal py-which-bufname "JPython") " -" "")))) ;; otherwise either run it synchronously in a subprocess - (shell-command-on-region start end cmd py-output-buffer) + (if (not input) + (shell-command-on-region start end cmd py-output-buffer) + (save-excursion + (set-buffer input) + (shell-command-on-region (point-min) (point-max) cmd + py-output-buffer)) + (kill-buffer input)) ;; shell-command-on-region kills the output buffer if it never ;; existed and there's no output from the command (if (not (get-buffer py-output-buffer)) -- François Pinard http://www.iro.umontreal.ca/~pinard From gpk@bell-labs.com Mon Apr 3 04:39:40 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Sun, 2 Apr 2000 23:39:40 -0400 (EDT) Subject: [Python-bugs-list] netrc module has bad error handling (PR#265) Message-ID: <20000403033940.C122E1CE16@dinsdale.python.org> Full_Name: Greg Kochanski Version: 1.5.2 OS: Solaris 2.6 Submission from: h-135-104-50-27.research.bell-labs.com (135.104.50.27) The constructor for netrc.netrc messes up royally if the file named file doesn't exist. In that case, it attempts to return None from the constructor as an error indication, rather than throwing an exception. Consequently, self.hosts is not initialized, and future attempts to use the class object will fail. You can't usefully return a value from a constructor. So, the code at the top of netrc.netrc.__init__() should be fp = open(file) rather than try: fp = open(file) except: return None BTW, Python ought to catch attempts to return values from constructors. From ajung@suxers.de Mon Apr 3 12:08:05 2000 From: ajung@suxers.de (ajung@suxers.de) Date: Mon, 3 Apr 2000 07:08:05 -0400 (EDT) Subject: [Python-bugs-list] s='somestring' still produces a ASCII string (PR#266) Message-ID: <20000403110805.9EA621CE80@dinsdale.python.org> Full_Name: Andreas Jung Version: Python 1.6a1 OS: Solaris 2.7 Submission from: flix.sz-sb.de (193.141.187.2) According to Guido's posting a statement like s = '....' should produce a unicode string. However type(s) says that s is a standard string - not a unicode one. Andreas Jung From ajung@suxers.de Mon Apr 3 12:08:35 2000 From: ajung@suxers.de (ajung@suxers.de) Date: Mon, 3 Apr 2000 07:08:35 -0400 (EDT) Subject: [Python-bugs-list] s='somestring' still produces a ASCII string (PR#267) Message-ID: <20000403110835.500341CE80@dinsdale.python.org> Full_Name: Andreas Jung Version: Python 1.6a1 OS: Solaris 2.7 Submission from: flix.sz-sb.de (193.141.187.2) According to Guido's posting a statement like s = '....' should produce a unicode string. However type(s) says that s is a standard string - not a unicode one. Andreas Jung From flight@hoffleit.de Mon Apr 3 13:32:12 2000 From: flight@hoffleit.de (flight@hoffleit.de) Date: Mon, 3 Apr 2000 08:32:12 -0400 (EDT) Subject: [Python-bugs-list] configure.in fails if libnet is present... (PR#268) Message-ID: <20000403123212.861971CDF7@dinsdale.python.org> --lMM8JwqTlfDpEaS6 Content-Type: multipart/mixed; boundary="NMuMz9nt05w80d4+" --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable configure.in (as in Python 1.5.2 and 1.6a1) has a flaw: There's a library libnet (http://www.packetfactory.net/libnet) for portable packet creation that provides a function socket. configure.in mistakes this library for BeOS's libnet library, and erroneously adds a "-lnet" to LIBS when this libnet library is present at compilation time. AFAICS from the comments in the file, the check for socket in libnet is only reasonable on BeOS systems. The attached patch therefore only runs this check on BeOS* systems. Gregor =20 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="configure.in.diff" Content-Transfer-Encoding: quoted-printable --- configure.in Mon Apr 3 13:07:18 2000 +++ configure.in.x Mon Apr 3 13:06:34 2000 @@ -541,20 +541,24 @@ AC_CHECK_LIB(dl, dlopen) # Dynamic linking for SunOS/Solaris and SYSV AC_CHECK_LIB(dld, shl_load) # Dynamic linking for HP-UX # Most SVR4 platforms (e.g. Solaris) need -lsocket and -lnsl. # However on SGI IRIX, these exist but are broken. # BeOS' sockets are stashed in libnet. case "$ac_sys_system" in IRIX*) ;; *) AC_CHECK_LIB(nsl, t_open, [LIBS=3D"-lnsl $LIBS"]) # SVR4 AC_CHECK_LIB(socket, socket, [LIBS=3D"-lsocket $LIBS"], [], $LIBS) # SVR4 = sockets +;; +esac +case "$ac_sys_system" in +BeOS*) AC_CHECK_LIB(net, socket, [LIBS=3D"-lnet $LIBS"], [], $LIBS) # BeOS ;; esac =20 AC_MSG_CHECKING(for --with-libs) AC_ARG_WITH(libs, [--with-libs=3D'lib1 ...' link against additional lib= s], [ AC_MSG_RESULT($withval) LIBS=3D"$withval $LIBS" ], AC_MSG_RESULT(no)) =20 --NMuMz9nt05w80d4+-- --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE46Hux3eVfDf25G40RAYsAAKCgaXXvDYljeovae+JcS1c8Kn8waQCg2UvV 7cp6j9fWcJOxziFNjRCXWw8= =J41q -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From bwarsaw@cnri.reston.va.us Mon Apr 3 14:11:42 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 3 Apr 2000 09:11:42 -0400 (EDT) Subject: [Python-bugs-list] s='somestring' still produces a ASCII string (PR#267) References: <20000403110835.500341CE80@dinsdale.python.org> Message-ID: <14568.39054.279400.396782@anthem.cnri.reston.va.us> >>>>> "ajung" == writes: | Full_Name: Andreas Jung | Version: Python 1.6a1 | OS: Solaris 2.7 | Submission from: flix.sz-sb.de (193.141.187.2) ajung> According to Guido's posting a statement like s = '....' ajung> should produce a unicode string. However type(s) says that ajung> s is a standard string - not a unicode one. Look closely of the date of Guido's post; it was an April Fools joke. But hey, even I was fooled for a minute or two :) -Barry From bwarsaw@cnri.reston.va.us Mon Apr 3 14:09:20 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Mon, 3 Apr 2000 09:09:20 -0400 (EDT) Subject: [Python-bugs-list] s='somestring' still produces a ASCII string (PR#267) Message-ID: <20000403130920.82DF81CE90@dinsdale.python.org> >>>>> "ajung" == writes: | Full_Name: Andreas Jung | Version: Python 1.6a1 | OS: Solaris 2.7 | Submission from: flix.sz-sb.de (193.141.187.2) ajung> According to Guido's posting a statement like s = '....' ajung> should produce a unicode string. However type(s) says that ajung> s is a standard string - not a unicode one. Look closely of the date of Guido's post; it was an April Fools joke. But hey, even I was fooled for a minute or two :) -Barry From skip@mojam.com (Skip Montanaro) Mon Apr 3 16:50:26 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 3 Apr 2000 10:50:26 -0500 (CDT) Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) In-Reply-To: <20000402212224.38C5B1CDB2@dinsdale.python.org> References: <20000402212224.38C5B1CDB2@dinsdale.python.org> Message-ID: <14568.48578.579998.389218@beluga.mojam.com> Fran=E7ois> File `Misc/python-mode.el' still has the problem that a= Fran=E7ois> region, part of a some bigger structure, may not be fed= to the Fran=E7ois> interpreter unless it is left-justified first. It is Fran=E7ois> cumbersome having to explicitly left-justify a region f= or Fran=E7ois> sending it, every time, and then undoing the Fran=E7ois> left-justification back in its normal place once sent. Wouldn't it be easier to have python-mode simply insert if 1: in front of any indented block of code being sent to the interpreter? --=20 Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ From mitch.harris@usa.net Mon Apr 3 18:29:31 2000 From: mitch.harris@usa.net (mitch.harris@usa.net) Date: Mon, 3 Apr 2000 13:29:31 -0400 (EDT) Subject: [Python-bugs-list] it don't make (PR#269) Message-ID: <20000403172931.878491CEA5@dinsdale.python.org> Full_Name: mitch harris Version: 1.6 OS: sun 5.6 Submission from: nat135022.ericy.com (208.237.135.22) First time I tried to install Python. /usr2/t_mitchh/python/Python-1.6a1>version Machine hardware: sun4u OS version: 5.6 Processor type: sparc Hardware: SUNW,Ultra-1 The following components are installed on your system: Sun Visual WorkShop C++ 3.0 Sun WorkShop Compiler C 4.2 Sun WorkShop Compiler C++ 4.2 Sun WorkShop Tools.h++ 7.0 Sun WorkShop Tools.h++ 6.0.4 Sun WorkShop Visual 2.0 Sun WorkShop IPE 4.0 Sun WorkShop CodeManager 2.0 Sun WorkShop Distributed Make 2.0 Sun WorkShop FileMerge 3.0 Sun WorkShop FreezePoint 2.0 Sun WorkShop Maketool 2.0 Sun WorkShop VersionTool 2.0 Sun WorkShop Dbx 4.0 Sun WorkShop Performance Analyzer 4.0 Sun WorkShop LoopTool 2.1 Sun WorkShop LockLint 2.1 Sun WorkShop Thread Analyzer 1.2 Sun WorkShop XEmacs 20.00 /usr2/t_mitchh/python/Python-1.6a1>./configure creating cache ./config.cache checking MACHDEP... sunos5 checking for --without-gcc... no checking for --with-cxx=... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... gcc -E checking for AIX... no checking for minix/config.h... no checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking for C preprocessor type... ansi checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... no checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... yes checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... yes checking for sys/file.h... no checking for sys/lock.h... yes checking for sys/param.h... no checking for sys/select.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 4 checking size of void *... 4 checking size of char... 1 checking size of short... 2 checking size of float... 4 checking size of double... 8 checking for long long support... yes checking size of long long... 8 checking size of off_t... 4 checking whether to enable large file support... no checking for --with-next-framework... no checking for --with-dyld... no checking SO... .so checking LDSHARED... ld -G checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for t_open in -lnsl... yes checking for socket in -lsocket... yes checking for socket in -lnet... no checking for --with-libs... no checking for --with(out)-readline... not specified. checking for --with-dec-threads... no checking for --with-threads... no checking for --with-thread... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for dlopen... yes checking DYNLOADFILE... dynload_shlib.o checking for alarm... yes checking for chown... yes checking for clock... yes checking for confstr... yes checking for ctermid... yes checking for ctermid_r... yes checking for dlopen... (cached) yes checking for execv... yes checking for flock... no checking for fork... yes checking for fsync... yes checking for fdatasync... no checking for fpathconf... yes checking for ftime... yes checking for ftruncate... yes checking for getgroups... yes checking for getlogin... yes checking for getpeername... yes checking for getpgrp... yes checking for getpid... yes checking for getpwent... yes checking for gettimeofday... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for nice... yes checking for pathconf... yes checking for pause... yes checking for plock... yes checking for pthread_init... no checking for putenv... yes checking for readlink... yes checking for select... yes checking for setgid... yes checking for setlocale... yes checking for setuid... yes checking for setsid... yes checking for setpgid... yes checking for setpgrp... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... yes checking for strftime... yes checking for strptime... yes checking for symlink... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for tempnam... yes checking for timegm... no checking for times... yes checking for tmpfile... yes checking for tmpnam... yes checking for tmpnam_r... yes checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for fseek64... no checking for fseeko... yes checking for fstatvfs... yes checking for ftell64... no checking for ftello... yes checking for statvfs... yes checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... (cached) yes checking for setpgrp... (cached) yes checking for gettimeofday... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... no checking for tzname... yes checking for time.h that defines altzone... yes checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for inline... inline checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... yes checking gethostbyname_r with 6 args... no checking gethostbyname_r with 5 args... no checking gethostbyname_r with 3 args... no checking for __fpu_control in -lieee... no checking for --with-fpectl... no checking for --with-libm=STRING... default LIBM="-lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for hypot... (cached) yes checking for genuine getopt... yes checking what malloc(0) returns... nonnull checking for wchar.h... yes checking for usable wchar_t... no checking whether byte ordering is bigendian... yes checking for --with-wctype-functions... no updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.thread creating config.h /usr2/t_mitchh/python/Python-1.6a1/Modules>make gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c In file included from ./posixmodule.c:3194: /usr/include/sys/statvfs.h:38: parse error before `fsblkcnt_t' /usr/include/sys/statvfs.h:38: warning: no semicolon at end of struct or union /usr/include/sys/statvfs.h:39: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:40: parse error before `f_bavail' /usr/include/sys/statvfs.h:40: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:41: parse error before `f_files' /usr/include/sys/statvfs.h:41: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:42: parse error before `f_ffree' /usr/include/sys/statvfs.h:42: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:43: parse error before `f_favail' /usr/include/sys/statvfs.h:43: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:51: parse error before `}' /usr/include/sys/statvfs.h:51: warning: data definition has no type or storage class ./posixmodule.c: In function `posix_fstatvfs': ./posixmodule.c:3207: storage size of `st' isn't known ./posixmodule.c: In function `posix_statvfs': ./posixmodule.c:3259: storage size of `st' isn't known make: *** [posixmodule.o] Error 1 I tried this #if defined(HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) #if defined(HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) #ifdef HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #ifdef HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx and got this /prj/qed2/local//lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1/include/sys/param.h:187: warning: `NBBY' r /usr/include/sys/select.h:45: warning: this is the location of the previous definition In file included from /usr/include/sys/stream.h:26, from /usr/include/netinet/in.h:38, from /usr/include/netdb.h:96, from ./socketmodule.c:163: /usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified" make[1]: *** [socketmodule.o] Error 1 make[1]: Leaving directory `/usr2/t_mitchh/python/Python-1.6a1/Modules' make: *** [Modules] Error 2 From pinard@iro.umontreal.ca Mon Apr 3 19:15:05 2000 From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) Date: 03 Apr 2000 14:15:05 -0400 Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) In-Reply-To: Skip Montanaro's message of "Mon, 3 Apr 2000 10:50:26 -0500 (CDT)" References: <20000402212224.38C5B1CDB2@dinsdale.python.org> <14568.48578.579998.389218@beluga.mojam.com> Message-ID: Skip Montanaro écrit: > François> File `Misc/python-mode.el' still has the problem that a > François> region, part of a some bigger structure, may not be fed to the > François> interpreter unless it is left-justified first. It is > François> cumbersome having to explicitly left-justify a region for > François> sending it, every time, and then undoing the > François> left-justification back in its normal place once sent. > Wouldn't it be easier to have python-mode simply insert > if 1: > in front of any indented block of code being sent to the interpreter? It might work indeed. But given that the patch exists for doing it neatly, why not just do it neatly? (The patch also avoids some spurious disk accesses when these are not needed.) In any case, I do not mind much, as long as something is done about it, so Python mode gets more useful. -- François Pinard http://www.iro.umontreal.ca/~pinard From skip@mojam.com (Skip Montanaro) Mon Apr 3 18:31:27 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 3 Apr 2000 12:31:27 -0500 (CDT) Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) In-Reply-To: References: <20000402212224.38C5B1CDB2@dinsdale.python.org> <14568.48578.579998.389218@beluga.mojam.com> Message-ID: <14568.54639.41337.172746@beluga.mojam.com> >> Wouldn't it be easier to have python-mode simply insert >> if 1: >> in front of any indented block of code being sent to the interpr= eter? Fran=E7ois> It might work indeed. But given that the patch exists = for Fran=E7ois> doing it neatly, why not just do it neatly?=20 It was just an observation. I generally can barely read Emacs Lisp the= se days, with all the conventions programmers must adhere to to get things= to work in at least four different versions (GNU Emacs and XEmacs in both windowed and non-windowed environments), so all I was doing was reactin= g to all the "+" lines in the diff and thinking that inserting "if 1:" would= be a simpler patch. Skip From pinard@iro.umontreal.ca Mon Apr 3 22:33:02 2000 From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) Date: 03 Apr 2000 17:33:02 -0400 Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) In-Reply-To: Skip Montanaro's message of "Mon, 3 Apr 2000 12:31:27 -0500 (CDT)" References: <20000402212224.38C5B1CDB2@dinsdale.python.org> <14568.48578.579998.389218@beluga.mojam.com> <14568.54639.41337.172746@beluga.mojam.com> Message-ID: Skip Montanaro écrit: > It was just an observation. [...] thinking that inserting "if 1:" > would be a simpler patch. It would surely be simpler, but would not solve the spurious disk accesses. I think that the correct patch is better. Everything we postpone remains to be done one of these days, and the TODO lists are long enough already! -- François Pinard http://www.iro.umontreal.ca/~pinard From guido@python.org Mon Apr 3 23:54:58 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 03 Apr 2000 18:54:58 -0400 Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) In-Reply-To: Your message of "Mon, 03 Apr 2000 12:31:27 CDT." <14568.54639.41337.172746@beluga.mojam.com> References: <20000402212224.38C5B1CDB2@dinsdale.python.org> <14568.48578.579998.389218@beluga.mojam.com> <14568.54639.41337.172746@beluga.mojam.com> Message-ID: <200004032254.SAA06303@eric.cnri.reston.va.us> > >> Wouldn't it be easier to have python-mode simply insert > > >> if 1: > > >> in front of any indented block of code being sent to the interpreter? > > François> It might work indeed. But given that the patch exists for > François> doing it neatly, why not just do it neatly? > > It was just an observation. I generally can barely read Emacs Lisp these > days, with all the conventions programmers must adhere to to get things to > work in at least four different versions (GNU Emacs and XEmacs in both > windowed and non-windowed environments), so all I was doing was reacting to > all the "+" lines in the diff and thinking that inserting "if 1:" would be a > simpler patch. Plus, inserting "if 1:" doesn't affect the value of multi-line triple-quoted strings. And who says that indenting is neater than inserting "if 1:"? (François said something about disk accesses that I don't understand...) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Apr 4 00:04:09 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 03 Apr 2000 19:04:09 -0400 Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) In-Reply-To: Your message of "Sun, 02 Apr 2000 16:57:13 EDT." <20000402205713.5F9041CDD6@dinsdale.python.org> References: <20000402205713.5F9041CDD6@dinsdale.python.org> Message-ID: <200004032304.TAA06405@eric.cnri.reston.va.us> > Hello. This is an installation report for Python 1.6a1 on a SuSE 6.2 > Linux system, using a 2.2.10 kernel, gcc 2.7.2 and GNU libc 2.1.1. I used > http://sunsite.doc.ic.ac.uk/Mirrors/ftp.python.org/pub/www.python.org to > get the distribution, as www.python.org was rejecting contact requests. > > The system I use is usually not Internet-connected (this complicates the > uploads a bit :-), and so, I will not be able to take advantage of the > nice module dynamic upload facilities that were described on Aprit 1st! :-) > > Python was configured using no special configuration switches, and > configuration seemingly completed without problems. Compilation yielded > a single diagnostic: > > -----> > make[1]: Entre dans le répertoire `/var/tmp/python-1.6a1/Modules' > ./timemodule.c: In function `time_strptime': > ./timemodule.c:428: warning: assignment makes pointer from integer without a cast > -----< Seems a bug in Linux -- apparently strptime() is not declared anywhere. Or if it is, it is in a header file of its own. Do you know which header file, and how I can know if it's a good idea to #include it? > The `make install' command, which was: > > -----> > make -f Makefile prefix=/usr/local/stow/python-1.6a1 exec_prefix=/usr/local/stow/python-1.6a1 install > -----< > > raised that difficulty: > > -----> > Creating directory /usr/local/stow/python-1.6a1/bin > mkdir: Ne peut créer le répertoire `/usr/local/stow/python-1.6a1/bin'.: No such file or directory > -----< > > Creating `/usr/local/stow/python-1.6a1' by hand and reinstalling allowed > Python to get in its place, yet for all Autoconf-igured packages I installed > here, this is not necessary so far that I remember. Maybe Python does > not use `mkinstalldirs' (I did not check)? If not, it should do similarly. There is reason to this (plus I don't like being told to follow the GNU guidelines -- Python is not GNU software :-). The directories named in $exec_prefix and $prefix must already exist. In your case, it seems that /usr/local/stow did not exist; is this correct? Anything under $*prefix will be created by the install script. The reason for requiring $*prefix to pre-exist is that (a) this is almost always the case (the prefix is typically /usr/local or /usr), and (b) if it doesn't exist, it's likely that the user made a typo (rather than that they wanted Python to create a brand new typo). That's why I don't use mkinstalldirs. > Auto-compilation of installed Python sources (I presume that the installation > is careful to use its own Python), yielded a few warnings and errors, > listed below: > > -----> > [...] > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/asynchat.py ... > Tab size set to 4 > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/asyncore.py ... > Tab size set to 4 > [...] > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre.py ... > Tab size set to 4 Oops, that's a debug message. Thanks! Fixed now -- the message is only printed with -v. > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre.py", line 17 > > ^ > SyntaxError: invalid syntax > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_compile.py ... > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_compile.py", line 16 > > ^ > SyntaxError: invalid syntax > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_constants.py ... > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_constants.py", line 17 > > ^ > SyntaxError: invalid syntax > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_parse.py ... > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_parse.py", line 18 > > ^ > SyntaxError: invalid syntax > [...] > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/test/test_pyexpat.py ... > : inconsistent tab/space usage > -----< Sorry! I accidentally checked in a version that still had the CRLF line endings. Fixed now. > And then, it seems the whole compilation is launched once more through: > > -----> > PYTHONPATH=/usr/local/stow/python-1.6a1/lib/python1.6 \ > ./python -O /usr/local/stow/python-1.6a1/lib/python1.6/compileall.py /usr/local/stow/python-1.6a1/lib/python1.6 > -----< > > yielding the same set errors for a second time. That's to create the .pyo files -- notice that it uses python -O the second time. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Apr 4 00:01:50 2000 From: guido@python.org (guido@python.org) Date: Mon, 3 Apr 2000 19:01:50 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000403230150.F02C21CEE3@dinsdale.python.org> > Hello. This is an installation report for Python 1.6a1 on a SuSE 6.2 > Linux system, using a 2.2.10 kernel, gcc 2.7.2 and GNU libc 2.1.1. I used > http://sunsite.doc.ic.ac.uk/Mirrors/ftp.python.org/pub/www.python.org to > get the distribution, as www.python.org was rejecting contact requests. > > The system I use is usually not Internet-connected (this complicates the > uploads a bit :-), and so, I will not be able to take advantage of the > nice module dynamic upload facilities that were described on Aprit 1st! :-) > > Python was configured using no special configuration switches, and > configuration seemingly completed without problems. Compilation yielded > a single diagnostic: > > -----> > make[1]: Entre dans le répertoire `/var/tmp/python-1.6a1/Modules' > ./timemodule.c: In function `time_strptime': > ./timemodule.c:428: warning: assignment makes pointer from integer without a cast > -----< Seems a bug in Linux -- apparently strptime() is not declared anywhere. Or if it is, it is in a header file of its own. Do you know which header file, and how I can know if it's a good idea to #include it? > The `make install' command, which was: > > -----> > make -f Makefile prefix=/usr/local/stow/python-1.6a1 exec_prefix=/usr/local/stow/python-1.6a1 install > -----< > > raised that difficulty: > > -----> > Creating directory /usr/local/stow/python-1.6a1/bin > mkdir: Ne peut créer le répertoire `/usr/local/stow/python-1.6a1/bin'.: No such file or directory > -----< > > Creating `/usr/local/stow/python-1.6a1' by hand and reinstalling allowed > Python to get in its place, yet for all Autoconf-igured packages I installed > here, this is not necessary so far that I remember. Maybe Python does > not use `mkinstalldirs' (I did not check)? If not, it should do similarly. There is reason to this (plus I don't like being told to follow the GNU guidelines -- Python is not GNU software :-). The directories named in $exec_prefix and $prefix must already exist. In your case, it seems that /usr/local/stow did not exist; is this correct? Anything under $*prefix will be created by the install script. The reason for requiring $*prefix to pre-exist is that (a) this is almost always the case (the prefix is typically /usr/local or /usr), and (b) if it doesn't exist, it's likely that the user made a typo (rather than that they wanted Python to create a brand new typo). That's why I don't use mkinstalldirs. > Auto-compilation of installed Python sources (I presume that the installation > is careful to use its own Python), yielded a few warnings and errors, > listed below: > > -----> > [...] > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/asynchat.py ... > Tab size set to 4 > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/asyncore.py ... > Tab size set to 4 > [...] > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre.py ... > Tab size set to 4 Oops, that's a debug message. Thanks! Fixed now -- the message is only printed with -v. > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre.py", line 17 > > ^ > SyntaxError: invalid syntax > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_compile.py ... > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_compile.py", line 16 > > ^ > SyntaxError: invalid syntax > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_constants.py ... > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_constants.py", line 17 > > ^ > SyntaxError: invalid syntax > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/sre_parse.py ... > File "/usr/local/stow/python-1.6a1/lib/python1.6/sre_parse.py", line 18 > > ^ > SyntaxError: invalid syntax > [...] > Compiling /usr/local/stow/python-1.6a1/lib/python1.6/test/test_pyexpat.py ... > : inconsistent tab/space usage > -----< Sorry! I accidentally checked in a version that still had the CRLF line endings. Fixed now. > And then, it seems the whole compilation is launched once more through: > > -----> > PYTHONPATH=/usr/local/stow/python-1.6a1/lib/python1.6 \ > ./python -O /usr/local/stow/python-1.6a1/lib/python1.6/compileall.py /usr/local/stow/python-1.6a1/lib/python1.6 > -----< > > yielding the same set errors for a second time. That's to create the .pyo files -- notice that it uses python -O the second time. --Guido van Rossum (home page: http://www.python.org/~guido/) From esr@thyrsus.com Tue Apr 4 00:23:28 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 3 Apr 2000 19:23:28 -0400 Subject: gpk@bell-labs.com: [Python-bugs-list] netrc module has bad error handling (PR#265) In-Reply-To: <200004032250.SAA06271@eric.cnri.reston.va.us>; from guido@python.org on Mon, Apr 03, 2000 at 06:50:52PM -0400 References: <200004032250.SAA06271@eric.cnri.reston.va.us> Message-ID: <20000403192328.A4548@thyrsus.com> Guido van Rossum : > Eric, > > Perhaps you can answer these two bug reports for your netrc.py module? Gladly. > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > Subject: [Python-bugs-list] netrc.py rejects hostnames (PR#243) > > From: lannert@uni-duesseldorf.de > > To: python-bugs-list@python.org > > Cc: bugs-py@python.org > > Date: Tue, 21 Mar 2000 19:07:53 -0500 (EST) > > Status: O > > X-Status: > > X-Keywords: > > X-UID: 276 > > > > Hi, > > > > I tried to use netrc.py but it chokes on my ~/.netrc: hostnames of the > > form spam.uni-duesseldorf.de are rejected because of the '-' character. > > > > The following patch against the CVS version made this module work (for > > me!): > > > > --- netrc.py~ Wed Mar 22 01:01:33 2000 > > +++ netrc.py Wed Mar 22 01:02:01 2000 > > @@ -15,7 +15,7 @@ > > self.hosts = {} > > self.macros = {} > > lexer = shlex.shlex(fp) > > - lexer.wordchars = lexer.wordchars + '.' > > + lexer.wordchars = lexer.wordchars + '.-' > > while 1: > > # Look for a machine, default, or macdef top-level keyword > > toplevel = tt = lexer.get_token() > > > > > > AFAIK, '-' is a legitimate hostname character; I don't think that this > > extended acceptance of the lexer could break anything else. I agree. I believe this patch is correct; thanks. > > BTW, the following lines: > > > > 31: lexer.whitepace = ' \t' > > 35: lexer.whitepace = ' \t\r\n' > > > > look a bit strange; shouldn't it be "whitespace" as defined in shlex? > > (But then, how did this ever work? :) This code is correct, though perhaps not as explicit as it should be. It is a workaround for the fact that macdefs actually have different lexical rules than the rest of the .netrc format. If you notice that the assignment on line 35 is actually restoring the shlex default I think you'll grok what's happening. It's kind of ugly, but that's not my fault :-). Go pound on whoever designed the .netrc format. > ------- Forwarded Message > > Date: Sun, 02 Apr 2000 23:39:40 -0400 > From: gpk@bell-labs.com > To: python-bugs-list@python.org > cc: bugs-py@python.org > Subject: [Python-bugs-list] netrc module has bad error handling (PR#265) > > Full_Name: Greg Kochanski > Version: 1.5.2 > OS: Solaris 2.6 > Submission from: h-135-104-50-27.research.bell-labs.com (135.104.50.27) > > > The constructor for netrc.netrc messes up royally > if the file named file doesn't exist. > > In that case, it attempts to return None > from the constructor as an error indication, > rather than throwing an exception. > Consequently, self.hosts is not initialized, > and future attempts to use the class object will > fail. You can't usefully return a value from a > constructor. > > So, the code at the top of netrc.netrc.__init__() should be > > fp = open(file) > > rather than > > try: > fp = open(file) > except: > return None > You are correct, sir. I was a rather new Pythoneer when I wrote this; this is a novice error. > BTW, Python ought to catch attempts to return values > from constructors. Probably so. Both these patches should be put in the masters by someone with commit authority. Guido, this reminds me that I have an updated and improved shlex that adds the capability to optionally support a file-inclusion construct at the lexical level, with proper stacking and unstacking of input sources. All the user has to do is say lexer.include = "include" or lexer.include = "source" or whatever to declare the inclusion keyword. The token after it is treated as a filename and becomes the input source. What's the current submission process? -- Eric S. Raymond If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report From guido@python.org Tue Apr 4 00:20:23 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 03 Apr 2000 19:20:23 -0400 Subject: gpk@bell-labs.com: [Python-bugs-list] netrc module has bad error handling (PR#265) In-Reply-To: Your message of "Mon, 03 Apr 2000 19:23:28 EDT." <20000403192328.A4548@thyrsus.com> References: <200004032250.SAA06271@eric.cnri.reston.va.us> <20000403192328.A4548@thyrsus.com> Message-ID: <200004032320.TAA06516@eric.cnri.reston.va.us> > Both these patches should be put in the masters by someone with > commit authority. > > Guido, this reminds me that I have an updated and improved shlex that > adds the capability to optionally support a file-inclusion construct > at the lexical level, with proper stacking and unstacking of input sources. > All the user has to do is say > > lexer.include = "include" > > or > > lexer.include = "source" > > or whatever to declare the inclusion keyword. The token after it is > treated as a filename and becomes the input source. > > What's the current submission process? See python.org/patches/. --Guido van Rossum (home page: http://www.python.org/~guido/) From pinard@iro.umontreal.ca Tue Apr 4 01:18:01 2000 From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) Date: 03 Apr 2000 20:18:01 -0400 Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) In-Reply-To: Guido van Rossum's message of "Mon, 03 Apr 2000 18:54:58 -0400" References: <20000402212224.38C5B1CDB2@dinsdale.python.org> <14568.48578.579998.389218@beluga.mojam.com> <14568.54639.41337.172746@beluga.mojam.com> <200004032254.SAA06303@eric.cnri.reston.va.us> Message-ID: Guido van Rossum écrit: > Plus, inserting "if 1:" doesn't affect the value of multi-line > triple-quoted strings. True. Python mode is rather weak about those. Each time I shift a block of lines left or right, I have to adjust these after the fact, while Python mode should ideally do it for me (it should now about the fact that multi-line strings are to be excluded from shift operations). > (François said something about disk accesses that I don't understand...) I do not even remember exactly myself. Python mode has three ways for submitting code to Python process, some of these require temporary files, while others do not. But Python mode produces temporary files even when they are not needed. I guess it was done this way to spare a few lines of Emacs LISP code, but I'm not sure this is good economy. -- François Pinard http://www.iro.umontreal.ca/~pinard From pinard@iro.umontreal.ca Tue Apr 4 01:54:58 2000 From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) Date: 03 Apr 2000 20:54:58 -0400 Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) In-Reply-To: Guido van Rossum's message of "Mon, 03 Apr 2000 19:04:09 -0400" References: <20000402205713.5F9041CDD6@dinsdale.python.org> <200004032304.TAA06405@eric.cnri.reston.va.us> Message-ID: Guido van Rossum écrit: > > Creating `/usr/local/stow/python-1.6a1' by hand and reinstalling > > allowed Python to get in its place, yet for all Autoconf-igured > > packages I installed here, this is not necessary so far that I remember. > > Maybe Python does not use `mkinstalldirs' (I did not check)? If not, > > it should do similarly. > There is reason to this (plus I don't like being told to follow the GNU > guidelines -- Python is not GNU software :-). I do not perceive Python as GNU software. I even confess this is part of my interest. After more than 12 years of intense work for the FSF by pure dedication, I'm now trying to widen my horizons, get out of my own mini-ivory tower, back in the big land, and participate to non-FSF free software. However, when an idea is good, it should not be dismissed on the sole premise that the FSF likes it. They are not _always_ wrong! :-). > In your case, it seems that /usr/local/stow did not exist; is this correct? `/usr/local/stow' existed, but `/usr/local/stow/python-1.6a1' did not. This is why the installation failed. I do all local installations here, through a big script automating them (which I wrote in Python :-). I easily modified that script for repairing the above problem on the fly: so it is not a problem anymore for me. However, it might be for anybody else using Stow, or Stow-like installations, so I think it was worth reporting, and probably worth correcting. Thanks for the other explanations in your reply (not repeated here). -- François Pinard http://www.iro.umontreal.ca/~pinard From pinard@iro.umontreal.ca Tue Apr 4 01:53:51 2000 From: pinard@iro.umontreal.ca (pinard@iro.umontreal.ca) Date: Mon, 3 Apr 2000 20:53:51 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000404005351.2FBB11CEA7@dinsdale.python.org> Guido van Rossum écrit: > > Creating `/usr/local/stow/python-1.6a1' by hand and reinstalling > > allowed Python to get in its place, yet for all Autoconf-igured > > packages I installed here, this is not necessary so far that I remember. > > Maybe Python does not use `mkinstalldirs' (I did not check)? If not, > > it should do similarly. > There is reason to this (plus I don't like being told to follow the GNU > guidelines -- Python is not GNU software :-). I do not perceive Python as GNU software. I even confess this is part of my interest. After more than 12 years of intense work for the FSF by pure dedication, I'm now trying to widen my horizons, get out of my own mini-ivory tower, back in the big land, and participate to non-FSF free software. However, when an idea is good, it should not be dismissed on the sole premise that the FSF likes it. They are not _always_ wrong! :-). > In your case, it seems that /usr/local/stow did not exist; is this correct? `/usr/local/stow' existed, but `/usr/local/stow/python-1.6a1' did not. This is why the installation failed. I do all local installations here, through a big script automating them (which I wrote in Python :-). I easily modified that script for repairing the above problem on the fly: so it is not a problem anymore for me. However, it might be for anybody else using Stow, or Stow-like installations, so I think it was worth reporting, and probably worth correcting. Thanks for the other explanations in your reply (not repeated here). -- François Pinard http://www.iro.umontreal.ca/~pinard From pinard@iro.umontreal.ca Tue Apr 4 02:20:07 2000 From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) Date: 03 Apr 2000 21:20:07 -0400 Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) In-Reply-To: Guido van Rossum's message of "Mon, 03 Apr 2000 19:04:09 -0400" References: <20000402205713.5F9041CDD6@dinsdale.python.org> <200004032304.TAA06405@eric.cnri.reston.va.us> Message-ID: --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Guido van Rossum écrit: > > ./timemodule.c: In function `time_strptime': > > ./timemodule.c:428: warning: assignment makes pointer from integer without a cast > Seems a bug in Linux -- apparently strptime() is not declared anywhere. > Or if it is, it is in a header file of its own. Do you know which header > file, and how I can know if it's a good idea to #include it? Grepping `/usr/include' found it in `/usr/include/time.h'. Here are the associated lines (I'm including it whole as a MIME attachment). # ifdef __USE_XOPEN /* Parse S according to FORMAT and store binary time information in TP. The return value is a pointer to the first unparsed character in S. */ extern char *strptime __P ((__const char *__s, __const char *__fmt, struct tm *__tp)); # endif It seems that `__USE_XOPEN' is defined from within `/usr/include/features.h' (also included whole below, as another attachment). Many system files include `features.h'. For it to be defined, `_XOPEN_SOURCE' has to be set at compilation time. This one, in turn, gets defined if `_GNU_SOURCE' is defined at compilation time, which I guarantee through `config.h' in the packages I distribute myself. This might be worth doing for Linux. --=-=-= Content-Disposition: attachment; filename=time.h /* Copyright (C) 1991,92,93,94,95,96,97,98,99 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with the GNU C Library; see the file COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* * ISO C Standard: 4.12 DATE and TIME */ #ifndef _TIME_H #if (! defined __need_time_t && !defined __need_clock_t && \ ! defined __need_timespec) # define _TIME_H 1 # include __BEGIN_DECLS #endif #ifdef _TIME_H /* Get size_t and NULL from . */ # define __need_size_t # define __need_NULL # include /* This defines CLOCKS_PER_SEC, which is the number of processor clock ticks per second. */ # include /* This is the obsolete POSIX.1-1988 name for the same constant. */ # ifdef __USE_POSIX # ifndef CLK_TCK # define CLK_TCK CLOCKS_PER_SEC # endif # endif #endif /* included. */ #if !defined __clock_t_defined && (defined _TIME_H || defined __need_clock_t) # define __clock_t_defined 1 # include /* Returned by `clock'. */ typedef __clock_t clock_t; #endif /* clock_t not defined and or need clock_t. */ #undef __need_clock_t #if !defined __time_t_defined && (defined _TIME_H || defined __need_time_t) # define __time_t_defined 1 # include /* Returned by `time'. */ typedef __time_t time_t; #endif /* time_t not defined and or need time_t. */ #undef __need_time_t #if !defined __timespec_defined && \ ((defined _TIME_H && defined __USE_POSIX199309) || defined __need_timespec) # define __timespec_defined 1 /* POSIX.4 structure for a time value. This is like a `struct timeval' but has nanoseconds instead of microseconds. */ struct timespec { long int tv_sec; /* Seconds. */ long int tv_nsec; /* Nanoseconds. */ }; #endif /* timespec not defined and or need timespec. */ #undef __need_timespec #ifdef _TIME_H /* Used by other time functions. */ struct tm { int tm_sec; /* Seconds. [0-60] (1 leap second) */ int tm_min; /* Minutes. [0-59] */ int tm_hour; /* Hours. [0-23] */ int tm_mday; /* Day. [1-31] */ int tm_mon; /* Month. [0-11] */ int tm_year; /* Year - 1900. */ int tm_wday; /* Day of week. [0-6] */ int tm_yday; /* Days in year.[0-365] */ int tm_isdst; /* DST. [-1/0/1]*/ # ifdef __USE_BSD long int tm_gmtoff; /* Seconds east of UTC. */ __const char *tm_zone; /* Timezone abbreviation. */ # else long int __tm_gmtoff; /* Seconds east of UTC. */ __const char *__tm_zone; /* Timezone abbreviation. */ # endif }; /* Time used by the program so far (user time + system time). The result / CLOCKS_PER_SECOND is program time in seconds. */ extern clock_t clock __P ((void)); /* Return the current time and put it in *TIMER if TIMER is not NULL. */ extern time_t time __P ((time_t *__timer)); /* Return the difference between TIME1 and TIME0. */ extern double difftime __P ((time_t __time1, time_t __time0)) __attribute__ ((__const__)); /* Return the `time_t' representation of TP and normalize TP. */ extern time_t mktime __P ((struct tm *__tp)); /* Format TP into S according to FORMAT. Write no more than MAXSIZE characters and return the number of characters written, or 0 if it would exceed MAXSIZE. */ extern size_t strftime __P ((char *__restrict __s, size_t __maxsize, __const char *__restrict __format, __const struct tm *__restrict __tp)); # ifdef __USE_XOPEN /* Parse S according to FORMAT and store binary time information in TP. The return value is a pointer to the first unparsed character in S. */ extern char *strptime __P ((__const char *__s, __const char *__fmt, struct tm *__tp)); # endif /* Return the `struct tm' representation of *TIMER in Universal Coordinated Time (aka Greenwich Mean Time). */ extern struct tm *gmtime __P ((__const time_t *__timer)); /* Return the `struct tm' representation of *TIMER in the local timezone. */ extern struct tm *localtime __P ((__const time_t *__timer)); # if defined __USE_POSIX || defined __USE_MISC /* Return the `struct tm' representation of *TIMER in UTC, using *TP to store the result. */ extern struct tm *__gmtime_r __P ((__const time_t *__restrict __timer, struct tm *__restrict __tp)); extern struct tm *gmtime_r __P ((__const time_t *__restrict __timer, struct tm *__restrict __tp)); /* Return the `struct tm' representation of *TIMER in local time, using *TP to store the result. */ extern struct tm *localtime_r __P ((__const time_t *__restrict __timer, struct tm *__restrict __tp)); # endif /* POSIX or misc */ /* Return a string of the form "Day Mon dd hh:mm:ss yyyy\n" that is the representation of TP in this format. */ extern char *asctime __P ((__const struct tm *__tp)); /* Equivalent to `asctime (localtime (timer))'. */ extern char *ctime __P ((__const time_t *__timer)); # if defined __USE_POSIX || defined __USE_MISC /* Reentrant versions of the above functions. */ /* Return in BUF a string of the form "Day Mon dd hh:mm:ss yyyy\n" that is the representation of TP in this format. */ extern char *asctime_r __P ((__const struct tm *__restrict __tp, char *__restrict __buf)); /* Equivalent to `asctime_r (localtime_r (timer, *TMP*), buf)'. */ extern char *ctime_r __P ((__const time_t *__restrict __timer, char *__restrict __buf)); # endif /* POSIX or misc */ /* Defined in localtime.c. */ extern char *__tzname[2]; /* Current timezone names. */ extern int __daylight; /* If daylight-saving time is ever in use. */ extern long int __timezone; /* Seconds west of UTC. */ # ifdef __USE_POSIX /* Same as above. */ extern char *tzname[2]; /* Set time conversion information from the TZ environment variable. If TZ is not defined, a locale-dependent default is used. */ extern void tzset __P ((void)); # endif # if defined __USE_SVID || defined __USE_XOPEN extern int daylight; extern long int timezone; # endif # ifdef __USE_SVID /* Set the system time to *WHEN. This call is restricted to the superuser. */ extern int stime __P ((__const time_t *__when)); # endif /* Nonzero if YEAR is a leap year (every 4 years, except every 100th isn't, and every 400th is). */ # define __isleap(year) \ ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0)) # ifdef __USE_MISC /* Miscellaneous functions many Unices inherited from the public domain localtime package. These are included only for compatibility. */ /* Like `mktime', but for TP represents Universal Time, not local time. */ extern time_t timegm __P ((struct tm *__tp)); /* Another name for `mktime'. */ extern time_t timelocal __P ((struct tm *__tp)); /* Return the number of days in YEAR. */ extern int dysize __P ((int __year)); # endif # ifdef __USE_POSIX199309 /* Pause execution for a number of nanoseconds. */ extern int nanosleep __P ((__const struct timespec *__requested_time, struct timespec *__remaining)); # endif # ifdef __USE_XOPEN_EXTENDED /* Set to one of the following values to indicate an error. 1 the DATEMSK environment variable is null or undefined, 2 the template file cannot be opened for reading, 3 failed to get file status information, 4 the template file is not a regular file, 5 an error is encountered while reading the template file, 6 memory allication failed (not enough memory available), 7 there is no line in the template that matches the input, 8 invalid input specification Example: February 31 or a time is specified that can not be represented in a time_t (representing the time in seconds since 00:00:00 UTC, January 1, 1970) */ extern int getdate_err; /* Parse the given string as a date specification and return a value representing the value. The templates from the file identified by the environment variable DATEMSK are used. In case of an error `getdate_err' is set. */ extern struct tm *getdate __P ((__const char *__string)); # endif # ifdef __USE_GNU /* Since `getdate' is not reentrant because of the use of `getdate_err' and the static buffer to return the result in, we provide a thread-safe variant. The functionality is the same. The result is returned in the buffer pointed to by RESBUFP and in case of an error the return value is != 0 with the same values as given above for `getdate_err'. */ extern int getdate_r __P ((__const char *__restrict __string, struct tm *__restrict __resbufp)); # endif __END_DECLS #endif /* included. */ #endif /* not already included. */ --=-=-= --=-=-= Content-Disposition: attachment; filename=features.h /* Copyright (C) 1991, 92, 93, 95, 96, 97, 98 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with the GNU C Library; see the file COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #ifndef _FEATURES_H #define _FEATURES_H 1 /* These are defined by the user (or the compiler) to specify the desired environment: __STRICT_ANSI__ ISO Standard C. _ISOC9X_SOURCE Extensions to ISO C 89 from ISO C 9x. _POSIX_SOURCE IEEE Std 1003.1. _POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2; if >=199309L, add IEEE Std 1003.1b-1993; if >=199506L, add IEEE Std 1003.1c-1995 _XOPEN_SOURCE Includes POSIX and XPG things. Set to 500 if Single Unix conformance is wanted. _XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions. _LARGEFILE_SOURCE Some more functions for correct standard I/O. _LARGEFILE64_SOURCE Additional functionality from LFS for large files. _FILE_OFFSET_BITS=N Select default filesystem interface. _BSD_SOURCE ISO C, POSIX, and 4.3BSD things. _SVID_SOURCE ISO C, POSIX, and SVID things. _GNU_SOURCE All of the above, plus GNU extensions. _REENTRANT Select additionally reentrant object. _THREAD_SAFE Same as _REENTRANT, often used by other systems. The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__. If none of these are defined, the default is all but _GNU_SOURCE. If more than one of these are defined, they accumulate. For example __STRICT_ANSI__, _POSIX_SOURCE and _POSIX_C_SOURCE together give you ISO C, 1003.1, and 1003.2, but nothing else. These are defined by this file and are used by the header files to decide what to declare or define: __USE_ISOC9X Define ISO C 9X things. __USE_POSIX Define IEEE Std 1003.1 things. __USE_POSIX2 Define IEEE Std 1003.2 things. __USE_POSIX199309 Define IEEE Std 1003.1, and .1b things. __USE_POSIX199506 Define IEEE Std 1003.1, .1b, .1c and .1i things. __USE_XOPEN Define XPG things. __USE_XOPEN_EXTENDED Define X/Open Unix things. __USE_UNIX98 Define Single Unix V2 things. __USE_LARGEFILE64 Define LFS things with separate names. __USE_FILE_OFFSET64 Define 64bit interface as default. __USE_BSD Define 4.3BSD things. __USE_SVID Define SVID things. __USE_MISC Define things common to BSD and System V Unix. __USE_GNU Define GNU extensions. __USE_REENTRANT Define reentrant/thread-safe *_r functions. __FAVOR_BSD Favor 4.3BSD things in cases of conflict. The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are defined by this file unconditionally. `__GNU_LIBRARY__' is provided only for compatibility. All new code should use the other symbols to test for features. All macros listed above as possibly being defined by this file are explicitly undefined if they are not explicitly defined. Feature-test macros that are not defined by the user or compiler but are implied by the other feature-test macros defined (or by the lack of any definitions) are defined by the file. */ /* Undefine everything, so we get a clean slate. */ #undef __USE_ISOC9X #undef __USE_POSIX #undef __USE_POSIX2 #undef __USE_POSIX199309 #undef __USE_POSIX199506 #undef __USE_XOPEN #undef __USE_XOPEN_EXTENDED #undef __USE_UNIX98 #undef __USE_LARGEFILE #undef __USE_LARGEFILE64 #undef __USE_FILE_OFFSET64 #undef __USE_BSD #undef __USE_SVID #undef __USE_MISC #undef __USE_GNU #undef __USE_REENTRANT #undef __FAVOR_BSD #undef __KERNEL_STRICT_NAMES /* Suppress kernel-name space pollution unless user expressedly asks for it. */ #ifndef _LOOSE_KERNEL_NAMES # define __KERNEL_STRICT_NAMES #endif /* Always use ISO C things. */ #define __USE_ANSI 1 /* If _BSD_SOURCE was defined by the user, favor BSD over POSIX. */ #if defined _BSD_SOURCE && \ !(defined _POSIX_SOURCE || defined _POSIX_C_SOURCE || \ defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED || \ defined _GNU_SOURCE || defined _SVID_SOURCE) # define __FAVOR_BSD 1 #endif /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE # undef _ISOC9X_SOURCE # define _ISOC9X_SOURCE 1 # undef _POSIX_SOURCE # define _POSIX_SOURCE 1 # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE 199506L # undef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 # undef _XOPEN_SOURCE_EXTENDED # define _XOPEN_SOURCE_EXTENDED 1 # undef _LARGEFILE64_SOURCE # define _LARGEFILE64_SOURCE 1 # undef _BSD_SOURCE # define _BSD_SOURCE 1 # undef _SVID_SOURCE # define _SVID_SOURCE 1 #endif /* If nothing (other than _GNU_SOURCE) is defined, define _BSD_SOURCE and _SVID_SOURCE. */ #if (!defined __STRICT_ANSI__ && !defined _ISOC9X_SOURCE && \ !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE && \ !defined _XOPEN_SOURCE && !defined _XOPEN_SOURCE_EXTENDED && \ !defined _BSD_SOURCE && !defined _SVID_SOURCE) # define _BSD_SOURCE 1 # define _SVID_SOURCE 1 #endif /* This is to enable the ISO C 9x extension. It will go away as soon as this standard is officially released. */ #ifdef _ISOC9X_SOURCE # define __USE_ISOC9X 1 #endif /* If none of the ANSI/POSIX macros are defined, use POSIX.1 and POSIX.2 (and IEEE Std 1003.1b-1993 unless _XOPEN_SOURCE is defined). */ #if (!defined __STRICT_ANSI__ && !defined _POSIX_SOURCE && \ !defined _POSIX_C_SOURCE) # define _POSIX_SOURCE 1 # if defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) != 500 # define _POSIX_C_SOURCE 2 # else # define _POSIX_C_SOURCE 199506L # endif #endif #if defined _POSIX_SOURCE || _POSIX_C_SOURCE >= 1 || defined _XOPEN_SOURCE # define __USE_POSIX 1 #endif #if defined _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 2 || defined _XOPEN_SOURCE # define __USE_POSIX2 1 #endif #if (_POSIX_C_SOURCE - 0) >= 199309L # define __USE_POSIX199309 1 #endif #if (_POSIX_C_SOURCE - 0) >= 199506L # define __USE_POSIX199506 1 #endif #ifdef _XOPEN_SOURCE # define __USE_XOPEN 1 # if (_XOPEN_SOURCE - 0) == 500 # define __USE_XOPEN_EXTENDED 1 # define __USE_UNIX98 1 # undef _LARGEFILE_SOURCE # define _LARGEFILE_SOURCE 1 # else # ifdef _XOPEN_SOURCE_EXTENDED # define __USE_XOPEN_EXTENDED 1 # endif # endif #endif #ifdef _LARGEFILE_SOURCE # define __USE_LARGEFILE 1 #endif #ifdef _LARGEFILE64_SOURCE # define __USE_LARGEFILE64 1 #endif #if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 # define __USE_FILE_OFFSET64 1 #endif #if defined _BSD_SOURCE || defined _SVID_SOURCE # define __USE_MISC 1 #endif #ifdef _BSD_SOURCE # define __USE_BSD 1 #endif #ifdef _SVID_SOURCE # define __USE_SVID 1 #endif #ifdef _GNU_SOURCE # define __USE_GNU 1 #endif #if defined _REENTRANT || defined _THREAD_SAFE # define __USE_REENTRANT 1 #endif /* We do support the IEC 559 math functionality, real and complex. */ #define __STDC_IEC_559__ 1 #define __STDC_IEC_559_COMPLEX__ 1 /* This macro indicates that the installed library is the GNU C Library. For historic reasons the value now is 6 and this will stay from now on. The use of this variable is deprecated. Use __GLIBC__ and __GLIBC_MINOR__ now (see below) when you want to test for a specific GNU C library version and use the values in to get the sonames of the shared libraries. */ #undef __GNU_LIBRARY__ #define __GNU_LIBRARY__ 6 /* Major and minor version number of the GNU C library package. Use these macros to test for features in specific releases. */ #define __GLIBC__ 2 #define __GLIBC_MINOR__ 1 /* This is here only because every header file already includes this one. */ #ifndef __ASSEMBLER__ # include /* If we don't have __REDIRECT, prototypes will be missing if __USE_FILE_OFFSET64 but not __USE_LARGEFILE[64]. */ # if defined __USE_FILE_OFFSET64 && !defined __REDIRECT # define __USE_LARGEFILE # define __USE_LARGEFILE64 # endif #endif /* !ASSEMBLER */ /* Decide whether we can define 'extern inline' functions in headers. */ #if defined __GNUC__ && (__GNUC__ > 2 || __GNUC__ == 2 && __GNUC_MINOR__ >= 7)\ && defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ # define __USE_EXTERN_INLINES 1 #endif /* This is here only because every header file already includes this one. */ #ifndef _LIBC /* Get the definitions of all the appropriate `__stub_FUNCTION' symbols. contains `#define __stub_FUNCTION' when FUNCTION is a stub which will always return failure (and set errno to ENOSYS). We avoid including when compiling the C library itself to avoid a dependency loop. stubs.h depends on every object file. If this #include were done for the library source code, then every object file would depend on stubs.h. */ # include #endif #endif /* features.h */ --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit -- François Pinard http://www.iro.umontreal.ca/~pinard --=-=-=-- From pinard@iro.umontreal.ca Tue Apr 4 02:18:53 2000 From: pinard@iro.umontreal.ca (pinard@iro.umontreal.ca) Date: Mon, 3 Apr 2000 21:18:53 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000404011853.4CE721CEA8@dinsdale.python.org> --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Guido van Rossum écrit: > > ./timemodule.c: In function `time_strptime': > > ./timemodule.c:428: warning: assignment makes pointer from integer without a cast > Seems a bug in Linux -- apparently strptime() is not declared anywhere. > Or if it is, it is in a header file of its own. Do you know which header > file, and how I can know if it's a good idea to #include it? Grepping `/usr/include' found it in `/usr/include/time.h'. Here are the associated lines (I'm including it whole as a MIME attachment). # ifdef __USE_XOPEN /* Parse S according to FORMAT and store binary time information in TP. The return value is a pointer to the first unparsed character in S. */ extern char *strptime __P ((__const char *__s, __const char *__fmt, struct tm *__tp)); # endif It seems that `__USE_XOPEN' is defined from within `/usr/include/features.h' (also included whole below, as another attachment). Many system files include `features.h'. For it to be defined, `_XOPEN_SOURCE' has to be set at compilation time. This one, in turn, gets defined if `_GNU_SOURCE' is defined at compilation time, which I guarantee through `config.h' in the packages I distribute myself. This might be worth doing for Linux. --=-=-= Content-Disposition: attachment; filename=time.h /* Copyright (C) 1991,92,93,94,95,96,97,98,99 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with the GNU C Library; see the file COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* * ISO C Standard: 4.12 DATE and TIME */ #ifndef _TIME_H #if (! defined __need_time_t && !defined __need_clock_t && \ ! defined __need_timespec) # define _TIME_H 1 # include __BEGIN_DECLS #endif #ifdef _TIME_H /* Get size_t and NULL from . */ # define __need_size_t # define __need_NULL # include /* This defines CLOCKS_PER_SEC, which is the number of processor clock ticks per second. */ # include /* This is the obsolete POSIX.1-1988 name for the same constant. */ # ifdef __USE_POSIX # ifndef CLK_TCK # define CLK_TCK CLOCKS_PER_SEC # endif # endif #endif /* included. */ #if !defined __clock_t_defined && (defined _TIME_H || defined __need_clock_t) # define __clock_t_defined 1 # include /* Returned by `clock'. */ typedef __clock_t clock_t; #endif /* clock_t not defined and or need clock_t. */ #undef __need_clock_t #if !defined __time_t_defined && (defined _TIME_H || defined __need_time_t) # define __time_t_defined 1 # include /* Returned by `time'. */ typedef __time_t time_t; #endif /* time_t not defined and or need time_t. */ #undef __need_time_t #if !defined __timespec_defined && \ ((defined _TIME_H && defined __USE_POSIX199309) || defined __need_timespec) # define __timespec_defined 1 /* POSIX.4 structure for a time value. This is like a `struct timeval' but has nanoseconds instead of microseconds. */ struct timespec { long int tv_sec; /* Seconds. */ long int tv_nsec; /* Nanoseconds. */ }; #endif /* timespec not defined and or need timespec. */ #undef __need_timespec #ifdef _TIME_H /* Used by other time functions. */ struct tm { int tm_sec; /* Seconds. [0-60] (1 leap second) */ int tm_min; /* Minutes. [0-59] */ int tm_hour; /* Hours. [0-23] */ int tm_mday; /* Day. [1-31] */ int tm_mon; /* Month. [0-11] */ int tm_year; /* Year - 1900. */ int tm_wday; /* Day of week. [0-6] */ int tm_yday; /* Days in year.[0-365] */ int tm_isdst; /* DST. [-1/0/1]*/ # ifdef __USE_BSD long int tm_gmtoff; /* Seconds east of UTC. */ __const char *tm_zone; /* Timezone abbreviation. */ # else long int __tm_gmtoff; /* Seconds east of UTC. */ __const char *__tm_zone; /* Timezone abbreviation. */ # endif }; /* Time used by the program so far (user time + system time). The result / CLOCKS_PER_SECOND is program time in seconds. */ extern clock_t clock __P ((void)); /* Return the current time and put it in *TIMER if TIMER is not NULL. */ extern time_t time __P ((time_t *__timer)); /* Return the difference between TIME1 and TIME0. */ extern double difftime __P ((time_t __time1, time_t __time0)) __attribute__ ((__const__)); /* Return the `time_t' representation of TP and normalize TP. */ extern time_t mktime __P ((struct tm *__tp)); /* Format TP into S according to FORMAT. Write no more than MAXSIZE characters and return the number of characters written, or 0 if it would exceed MAXSIZE. */ extern size_t strftime __P ((char *__restrict __s, size_t __maxsize, __const char *__restrict __format, __const struct tm *__restrict __tp)); # ifdef __USE_XOPEN /* Parse S according to FORMAT and store binary time information in TP. The return value is a pointer to the first unparsed character in S. */ extern char *strptime __P ((__const char *__s, __const char *__fmt, struct tm *__tp)); # endif /* Return the `struct tm' representation of *TIMER in Universal Coordinated Time (aka Greenwich Mean Time). */ extern struct tm *gmtime __P ((__const time_t *__timer)); /* Return the `struct tm' representation of *TIMER in the local timezone. */ extern struct tm *localtime __P ((__const time_t *__timer)); # if defined __USE_POSIX || defined __USE_MISC /* Return the `struct tm' representation of *TIMER in UTC, using *TP to store the result. */ extern struct tm *__gmtime_r __P ((__const time_t *__restrict __timer, struct tm *__restrict __tp)); extern struct tm *gmtime_r __P ((__const time_t *__restrict __timer, struct tm *__restrict __tp)); /* Return the `struct tm' representation of *TIMER in local time, using *TP to store the result. */ extern struct tm *localtime_r __P ((__const time_t *__restrict __timer, struct tm *__restrict __tp)); # endif /* POSIX or misc */ /* Return a string of the form "Day Mon dd hh:mm:ss yyyy\n" that is the representation of TP in this format. */ extern char *asctime __P ((__const struct tm *__tp)); /* Equivalent to `asctime (localtime (timer))'. */ extern char *ctime __P ((__const time_t *__timer)); # if defined __USE_POSIX || defined __USE_MISC /* Reentrant versions of the above functions. */ /* Return in BUF a string of the form "Day Mon dd hh:mm:ss yyyy\n" that is the representation of TP in this format. */ extern char *asctime_r __P ((__const struct tm *__restrict __tp, char *__restrict __buf)); /* Equivalent to `asctime_r (localtime_r (timer, *TMP*), buf)'. */ extern char *ctime_r __P ((__const time_t *__restrict __timer, char *__restrict __buf)); # endif /* POSIX or misc */ /* Defined in localtime.c. */ extern char *__tzname[2]; /* Current timezone names. */ extern int __daylight; /* If daylight-saving time is ever in use. */ extern long int __timezone; /* Seconds west of UTC. */ # ifdef __USE_POSIX /* Same as above. */ extern char *tzname[2]; /* Set time conversion information from the TZ environment variable. If TZ is not defined, a locale-dependent default is used. */ extern void tzset __P ((void)); # endif # if defined __USE_SVID || defined __USE_XOPEN extern int daylight; extern long int timezone; # endif # ifdef __USE_SVID /* Set the system time to *WHEN. This call is restricted to the superuser. */ extern int stime __P ((__const time_t *__when)); # endif /* Nonzero if YEAR is a leap year (every 4 years, except every 100th isn't, and every 400th is). */ # define __isleap(year) \ ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0)) # ifdef __USE_MISC /* Miscellaneous functions many Unices inherited from the public domain localtime package. These are included only for compatibility. */ /* Like `mktime', but for TP represents Universal Time, not local time. */ extern time_t timegm __P ((struct tm *__tp)); /* Another name for `mktime'. */ extern time_t timelocal __P ((struct tm *__tp)); /* Return the number of days in YEAR. */ extern int dysize __P ((int __year)); # endif # ifdef __USE_POSIX199309 /* Pause execution for a number of nanoseconds. */ extern int nanosleep __P ((__const struct timespec *__requested_time, struct timespec *__remaining)); # endif # ifdef __USE_XOPEN_EXTENDED /* Set to one of the following values to indicate an error. 1 the DATEMSK environment variable is null or undefined, 2 the template file cannot be opened for reading, 3 failed to get file status information, 4 the template file is not a regular file, 5 an error is encountered while reading the template file, 6 memory allication failed (not enough memory available), 7 there is no line in the template that matches the input, 8 invalid input specification Example: February 31 or a time is specified that can not be represented in a time_t (representing the time in seconds since 00:00:00 UTC, January 1, 1970) */ extern int getdate_err; /* Parse the given string as a date specification and return a value representing the value. The templates from the file identified by the environment variable DATEMSK are used. In case of an error `getdate_err' is set. */ extern struct tm *getdate __P ((__const char *__string)); # endif # ifdef __USE_GNU /* Since `getdate' is not reentrant because of the use of `getdate_err' and the static buffer to return the result in, we provide a thread-safe variant. The functionality is the same. The result is returned in the buffer pointed to by RESBUFP and in case of an error the return value is != 0 with the same values as given above for `getdate_err'. */ extern int getdate_r __P ((__const char *__restrict __string, struct tm *__restrict __resbufp)); # endif __END_DECLS #endif /* included. */ #endif /* not already included. */ --=-=-= --=-=-= Content-Disposition: attachment; filename=features.h /* Copyright (C) 1991, 92, 93, 95, 96, 97, 98 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with the GNU C Library; see the file COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #ifndef _FEATURES_H #define _FEATURES_H 1 /* These are defined by the user (or the compiler) to specify the desired environment: __STRICT_ANSI__ ISO Standard C. _ISOC9X_SOURCE Extensions to ISO C 89 from ISO C 9x. _POSIX_SOURCE IEEE Std 1003.1. _POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2; if >=199309L, add IEEE Std 1003.1b-1993; if >=199506L, add IEEE Std 1003.1c-1995 _XOPEN_SOURCE Includes POSIX and XPG things. Set to 500 if Single Unix conformance is wanted. _XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions. _LARGEFILE_SOURCE Some more functions for correct standard I/O. _LARGEFILE64_SOURCE Additional functionality from LFS for large files. _FILE_OFFSET_BITS=N Select default filesystem interface. _BSD_SOURCE ISO C, POSIX, and 4.3BSD things. _SVID_SOURCE ISO C, POSIX, and SVID things. _GNU_SOURCE All of the above, plus GNU extensions. _REENTRANT Select additionally reentrant object. _THREAD_SAFE Same as _REENTRANT, often used by other systems. The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__. If none of these are defined, the default is all but _GNU_SOURCE. If more than one of these are defined, they accumulate. For example __STRICT_ANSI__, _POSIX_SOURCE and _POSIX_C_SOURCE together give you ISO C, 1003.1, and 1003.2, but nothing else. These are defined by this file and are used by the header files to decide what to declare or define: __USE_ISOC9X Define ISO C 9X things. __USE_POSIX Define IEEE Std 1003.1 things. __USE_POSIX2 Define IEEE Std 1003.2 things. __USE_POSIX199309 Define IEEE Std 1003.1, and .1b things. __USE_POSIX199506 Define IEEE Std 1003.1, .1b, .1c and .1i things. __USE_XOPEN Define XPG things. __USE_XOPEN_EXTENDED Define X/Open Unix things. __USE_UNIX98 Define Single Unix V2 things. __USE_LARGEFILE64 Define LFS things with separate names. __USE_FILE_OFFSET64 Define 64bit interface as default. __USE_BSD Define 4.3BSD things. __USE_SVID Define SVID things. __USE_MISC Define things common to BSD and System V Unix. __USE_GNU Define GNU extensions. __USE_REENTRANT Define reentrant/thread-safe *_r functions. __FAVOR_BSD Favor 4.3BSD things in cases of conflict. The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are defined by this file unconditionally. `__GNU_LIBRARY__' is provided only for compatibility. All new code should use the other symbols to test for features. All macros listed above as possibly being defined by this file are explicitly undefined if they are not explicitly defined. Feature-test macros that are not defined by the user or compiler but are implied by the other feature-test macros defined (or by the lack of any definitions) are defined by the file. */ /* Undefine everything, so we get a clean slate. */ #undef __USE_ISOC9X #undef __USE_POSIX #undef __USE_POSIX2 #undef __USE_POSIX199309 #undef __USE_POSIX199506 #undef __USE_XOPEN #undef __USE_XOPEN_EXTENDED #undef __USE_UNIX98 #undef __USE_LARGEFILE #undef __USE_LARGEFILE64 #undef __USE_FILE_OFFSET64 #undef __USE_BSD #undef __USE_SVID #undef __USE_MISC #undef __USE_GNU #undef __USE_REENTRANT #undef __FAVOR_BSD #undef __KERNEL_STRICT_NAMES /* Suppress kernel-name space pollution unless user expressedly asks for it. */ #ifndef _LOOSE_KERNEL_NAMES # define __KERNEL_STRICT_NAMES #endif /* Always use ISO C things. */ #define __USE_ANSI 1 /* If _BSD_SOURCE was defined by the user, favor BSD over POSIX. */ #if defined _BSD_SOURCE && \ !(defined _POSIX_SOURCE || defined _POSIX_C_SOURCE || \ defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED || \ defined _GNU_SOURCE || defined _SVID_SOURCE) # define __FAVOR_BSD 1 #endif /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE # undef _ISOC9X_SOURCE # define _ISOC9X_SOURCE 1 # undef _POSIX_SOURCE # define _POSIX_SOURCE 1 # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE 199506L # undef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 # undef _XOPEN_SOURCE_EXTENDED # define _XOPEN_SOURCE_EXTENDED 1 # undef _LARGEFILE64_SOURCE # define _LARGEFILE64_SOURCE 1 # undef _BSD_SOURCE # define _BSD_SOURCE 1 # undef _SVID_SOURCE # define _SVID_SOURCE 1 #endif /* If nothing (other than _GNU_SOURCE) is defined, define _BSD_SOURCE and _SVID_SOURCE. */ #if (!defined __STRICT_ANSI__ && !defined _ISOC9X_SOURCE && \ !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE && \ !defined _XOPEN_SOURCE && !defined _XOPEN_SOURCE_EXTENDED && \ !defined _BSD_SOURCE && !defined _SVID_SOURCE) # define _BSD_SOURCE 1 # define _SVID_SOURCE 1 #endif /* This is to enable the ISO C 9x extension. It will go away as soon as this standard is officially released. */ #ifdef _ISOC9X_SOURCE # define __USE_ISOC9X 1 #endif /* If none of the ANSI/POSIX macros are defined, use POSIX.1 and POSIX.2 (and IEEE Std 1003.1b-1993 unless _XOPEN_SOURCE is defined). */ #if (!defined __STRICT_ANSI__ && !defined _POSIX_SOURCE && \ !defined _POSIX_C_SOURCE) # define _POSIX_SOURCE 1 # if defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) != 500 # define _POSIX_C_SOURCE 2 # else # define _POSIX_C_SOURCE 199506L # endif #endif #if defined _POSIX_SOURCE || _POSIX_C_SOURCE >= 1 || defined _XOPEN_SOURCE # define __USE_POSIX 1 #endif #if defined _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 2 || defined _XOPEN_SOURCE # define __USE_POSIX2 1 #endif #if (_POSIX_C_SOURCE - 0) >= 199309L # define __USE_POSIX199309 1 #endif #if (_POSIX_C_SOURCE - 0) >= 199506L # define __USE_POSIX199506 1 #endif #ifdef _XOPEN_SOURCE # define __USE_XOPEN 1 # if (_XOPEN_SOURCE - 0) == 500 # define __USE_XOPEN_EXTENDED 1 # define __USE_UNIX98 1 # undef _LARGEFILE_SOURCE # define _LARGEFILE_SOURCE 1 # else # ifdef _XOPEN_SOURCE_EXTENDED # define __USE_XOPEN_EXTENDED 1 # endif # endif #endif #ifdef _LARGEFILE_SOURCE # define __USE_LARGEFILE 1 #endif #ifdef _LARGEFILE64_SOURCE # define __USE_LARGEFILE64 1 #endif #if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 # define __USE_FILE_OFFSET64 1 #endif #if defined _BSD_SOURCE || defined _SVID_SOURCE # define __USE_MISC 1 #endif #ifdef _BSD_SOURCE # define __USE_BSD 1 #endif #ifdef _SVID_SOURCE # define __USE_SVID 1 #endif #ifdef _GNU_SOURCE # define __USE_GNU 1 #endif #if defined _REENTRANT || defined _THREAD_SAFE # define __USE_REENTRANT 1 #endif /* We do support the IEC 559 math functionality, real and complex. */ #define __STDC_IEC_559__ 1 #define __STDC_IEC_559_COMPLEX__ 1 /* This macro indicates that the installed library is the GNU C Library. For historic reasons the value now is 6 and this will stay from now on. The use of this variable is deprecated. Use __GLIBC__ and __GLIBC_MINOR__ now (see below) when you want to test for a specific GNU C library version and use the values in to get the sonames of the shared libraries. */ #undef __GNU_LIBRARY__ #define __GNU_LIBRARY__ 6 /* Major and minor version number of the GNU C library package. Use these macros to test for features in specific releases. */ #define __GLIBC__ 2 #define __GLIBC_MINOR__ 1 /* This is here only because every header file already includes this one. */ #ifndef __ASSEMBLER__ # include /* If we don't have __REDIRECT, prototypes will be missing if __USE_FILE_OFFSET64 but not __USE_LARGEFILE[64]. */ # if defined __USE_FILE_OFFSET64 && !defined __REDIRECT # define __USE_LARGEFILE # define __USE_LARGEFILE64 # endif #endif /* !ASSEMBLER */ /* Decide whether we can define 'extern inline' functions in headers. */ #if defined __GNUC__ && (__GNUC__ > 2 || __GNUC__ == 2 && __GNUC_MINOR__ >= 7)\ && defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ # define __USE_EXTERN_INLINES 1 #endif /* This is here only because every header file already includes this one. */ #ifndef _LIBC /* Get the definitions of all the appropriate `__stub_FUNCTION' symbols. contains `#define __stub_FUNCTION' when FUNCTION is a stub which will always return failure (and set errno to ENOSYS). We avoid including when compiling the C library itself to avoid a dependency loop. stubs.h depends on every object file. If this #include were done for the library source code, then every object file would depend on stubs.h. */ # include #endif #endif /* features.h */ --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit -- François Pinard http://www.iro.umontreal.ca/~pinard --=-=-=-- From jgreene@combichem.com Tue Apr 4 03:02:10 2000 From: jgreene@combichem.com (jgreene@combichem.com) Date: Mon, 3 Apr 2000 22:02:10 -0400 (EDT) Subject: [Python-bugs-list] Py_FindMethod not documented (PR#270) Message-ID: <20000404020210.3A15B1CE98@dinsdale.python.org> Full_Name: Jonathan Greene Version: 1.5.2 OS: any Submission from: kalahari.dupontpharma.com (204.249.5.6) This function, important in writing extension modules, does not appear in the documentation. It should at least be listed in the API documentation, no? From guido@python.org Tue Apr 4 03:58:23 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 03 Apr 2000 22:58:23 -0400 Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) In-Reply-To: Your message of "03 Apr 2000 20:54:58 EDT." References: <20000402205713.5F9041CDD6@dinsdale.python.org> <200004032304.TAA06405@eric.cnri.reston.va.us> Message-ID: <200004040258.WAA10728@eric.cnri.reston.va.us> > > There is reason to this (plus I don't like being told to follow the GNU > > guidelines -- Python is not GNU software :-). > > I do not perceive Python as GNU software. I even confess this is part of > my interest. After more than 12 years of intense work for the FSF by pure > dedication, I'm now trying to widen my horizons, get out of my own mini-ivory > tower, back in the big land, and participate to non-FSF free software. Note the smiley in my message :-) > However, when an idea is good, it should not be dismissed on the sole > premise that the FSF likes it. They are not _always_ wrong! :-). And I didn't say that. > > In your case, it seems that /usr/local/stow did not exist; is this correct? > > `/usr/local/stow' existed, but `/usr/local/stow/python-1.6a1' did not. > This is why the installation failed. And you specified /usr/local/stow/python-1.6a1 as the (exec_)prefix, right? I don't know enough about stow to know if this is reasonable; basically, it seems you'll be using a different prefix for each version of each app then. This is not the assumption that the install script makes, and I think this is why it failed. > I do all local installations here, > through a big script automating them (which I wrote in Python :-). I easily > modified that script for repairing the above problem on the fly: so it > is not a problem anymore for me. However, it might be for anybody else > using Stow, or Stow-like installations, so I think it was worth reporting, > and probably worth correcting. Excuse my innocence, but perhaps you can explain in a few sentences how Stow works then? This certainly hasn't come up with Linux installs before, so I wonder what is special about Stow, and what kind of problems it is trying to solve that makes it important for me to deal with it. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Apr 4 03:56:07 2000 From: guido@python.org (guido@python.org) Date: Mon, 3 Apr 2000 22:56:07 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000404025607.D28F21CEAF@dinsdale.python.org> > > There is reason to this (plus I don't like being told to follow the GNU > > guidelines -- Python is not GNU software :-). > > I do not perceive Python as GNU software. I even confess this is part of > my interest. After more than 12 years of intense work for the FSF by pure > dedication, I'm now trying to widen my horizons, get out of my own mini-ivory > tower, back in the big land, and participate to non-FSF free software. Note the smiley in my message :-) > However, when an idea is good, it should not be dismissed on the sole > premise that the FSF likes it. They are not _always_ wrong! :-). And I didn't say that. > > In your case, it seems that /usr/local/stow did not exist; is this correct? > > `/usr/local/stow' existed, but `/usr/local/stow/python-1.6a1' did not. > This is why the installation failed. And you specified /usr/local/stow/python-1.6a1 as the (exec_)prefix, right? I don't know enough about stow to know if this is reasonable; basically, it seems you'll be using a different prefix for each version of each app then. This is not the assumption that the install script makes, and I think this is why it failed. > I do all local installations here, > through a big script automating them (which I wrote in Python :-). I easily > modified that script for repairing the above problem on the fly: so it > is not a problem anymore for me. However, it might be for anybody else > using Stow, or Stow-like installations, so I think it was worth reporting, > and probably worth correcting. Excuse my innocence, but perhaps you can explain in a few sentences how Stow works then? This certainly hasn't come up with Linux installs before, so I wonder what is special about Stow, and what kind of problems it is trying to solve that makes it important for me to deal with it. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Apr 4 04:05:11 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 03 Apr 2000 23:05:11 -0400 Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) In-Reply-To: Your message of "03 Apr 2000 21:20:07 EDT." References: <20000402205713.5F9041CDD6@dinsdale.python.org> <200004032304.TAA06405@eric.cnri.reston.va.us> Message-ID: <200004040305.XAA11241@eric.cnri.reston.va.us> > > Seems a bug in Linux -- apparently strptime() is not declared anywhere. > > Or if it is, it is in a header file of its own. Do you know which header > > file, and how I can know if it's a good idea to #include it? > > Grepping `/usr/include' found it in `/usr/include/time.h'. Here are the > associated lines (I'm including it whole as a MIME attachment). > > # ifdef __USE_XOPEN > /* Parse S according to FORMAT and store binary time information in TP. > The return value is a pointer to the first unparsed character in S. *= > / > extern char *strptime __P ((__const char *__s, __const char *__fmt, > struct tm *__tp)); > # endif > > > It seems that `__USE_XOPEN' is defined from within `/usr/include/features= > .h' > (also included whole below, as another attachment). Many system files > include `features.h'. For it to be defined, `_XOPEN_SOURCE' has to be se= > t > at compilation time. This one, in turn, gets defined if `_GNU_SOURCE' > is defined at compilation time, which I guarantee through `config.h' > in the packages I distribute myself. This might be worth doing for Linux. I have to admit I am very naive about all the symbols that various vendors (and GNU) require you to define in order to enable various variants of their libraries and/or header files. I was hoping that autoconf would do this -- but apparently it doesn't or I must still tell it to. I also don't know what the typical downside might be of turning on such symbols. Can you suggest a patch to configure.in that does the right thing? I simply don't have the background knowledge to decide what to do here, and the danger exists that if there's a complaint only from a small corner of the universe that it is their responsibility to send me a patch that doesn't break other corners of the universe -- I can't possibly know what's right for all. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Apr 4 04:02:53 2000 From: guido@python.org (guido@python.org) Date: Mon, 3 Apr 2000 23:02:53 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000404030253.5D2B51CEE8@dinsdale.python.org> > > Seems a bug in Linux -- apparently strptime() is not declared anywhere. > > Or if it is, it is in a header file of its own. Do you know which header > > file, and how I can know if it's a good idea to #include it? > > Grepping `/usr/include' found it in `/usr/include/time.h'. Here are the > associated lines (I'm including it whole as a MIME attachment). > > # ifdef __USE_XOPEN > /* Parse S according to FORMAT and store binary time information in TP. > The return value is a pointer to the first unparsed character in S. *= > / > extern char *strptime __P ((__const char *__s, __const char *__fmt, > struct tm *__tp)); > # endif > > > It seems that `__USE_XOPEN' is defined from within `/usr/include/features= > .h' > (also included whole below, as another attachment). Many system files > include `features.h'. For it to be defined, `_XOPEN_SOURCE' has to be se= > t > at compilation time. This one, in turn, gets defined if `_GNU_SOURCE' > is defined at compilation time, which I guarantee through `config.h' > in the packages I distribute myself. This might be worth doing for Linux. I have to admit I am very naive about all the symbols that various vendors (and GNU) require you to define in order to enable various variants of their libraries and/or header files. I was hoping that autoconf would do this -- but apparently it doesn't or I must still tell it to. I also don't know what the typical downside might be of turning on such symbols. Can you suggest a patch to configure.in that does the right thing? I simply don't have the background knowledge to decide what to do here, and the danger exists that if there's a complaint only from a small corner of the universe that it is their responsibility to send me a patch that doesn't break other corners of the universe -- I can't possibly know what's right for all. --Guido van Rossum (home page: http://www.python.org/~guido/) From pinard@iro.umontreal.ca Tue Apr 4 04:50:52 2000 From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) Date: 03 Apr 2000 23:50:52 -0400 Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) In-Reply-To: Guido van Rossum's message of "Mon, 03 Apr 2000 22:58:23 -0400" References: <20000402205713.5F9041CDD6@dinsdale.python.org> <200004032304.TAA06405@eric.cnri.reston.va.us> <200004040258.WAA10728@eric.cnri.reston.va.us> Message-ID: Guido van Rossum writes: > And you specified /usr/local/stow/python-1.6a1 as the (exec_)prefix, right? Yes. > it seems you'll be using a different prefix for each version of each > app then. This is not the assumption that the install script makes, Of course. The idea behind Stow is to install each package in its own hierarchy, while compiling it to run elsewhere (in `/usr/local' usually). Stow then (cleverly) establishes symbolic links between `/usr/local' and where the package has been really installed. This allows for quick and easy un-installation of packages, and also for quick and easy switching between installed versions. Automake and Autoconf support Stow, but unofficially, from the fact that one can do: ./configure --prefix=/usr/local and make install prefix=/usr/local/stow/python-1.6a1 without adverse effect. The missing step, once Stow is available, is: cd /usr/local/stow && stow python-1.6a1 Stow is discussed from time to time in the Gnits gang, where Automake (and many other things :-) have been brain-stormed. Stow is distributed by the FSF, and its author was working on a rewrite from Perl to C, the last time I heard of it. It is currently distributed by the FSF. An alternative to Stow is building `RPM's, but these requires more work than a mere installer is usually prepared to do. Stow is easy. > This certainly hasn't come up with Linux installs before, so I wonder > what is special about Stow, and what kind of problems it is trying to > solve that makes it important for me to deal with it. There are many things that can become popular because we did manage to make room for them, or (I'm not sure the idiom translates in English) because "we prepared the field". Autoconf and gettext are good examples, but there are a lot of tiny and humble things in this case, which have been prepared for a long time (and often after exhausting discussions :-), and then became of wider use. My feeling is that Stow is one of these things that is worth our favour, also given that once a package properly uses the Autoconf/Automake machinery, the extra effort needed for Stow support is small. I'm not saying it is important, but I think it is a good bet. -- François Pinard http://www.iro.umontreal.ca/~pinard From pinard@iro.umontreal.ca Tue Apr 4 04:49:43 2000 From: pinard@iro.umontreal.ca (pinard@iro.umontreal.ca) Date: Mon, 3 Apr 2000 23:49:43 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000404034943.5679F1CEF2@dinsdale.python.org> Guido van Rossum writes: > And you specified /usr/local/stow/python-1.6a1 as the (exec_)prefix, right? Yes. > it seems you'll be using a different prefix for each version of each > app then. This is not the assumption that the install script makes, Of course. The idea behind Stow is to install each package in its own hierarchy, while compiling it to run elsewhere (in `/usr/local' usually). Stow then (cleverly) establishes symbolic links between `/usr/local' and where the package has been really installed. This allows for quick and easy un-installation of packages, and also for quick and easy switching between installed versions. Automake and Autoconf support Stow, but unofficially, from the fact that one can do: ./configure --prefix=/usr/local and make install prefix=/usr/local/stow/python-1.6a1 without adverse effect. The missing step, once Stow is available, is: cd /usr/local/stow && stow python-1.6a1 Stow is discussed from time to time in the Gnits gang, where Automake (and many other things :-) have been brain-stormed. Stow is distributed by the FSF, and its author was working on a rewrite from Perl to C, the last time I heard of it. It is currently distributed by the FSF. An alternative to Stow is building `RPM's, but these requires more work than a mere installer is usually prepared to do. Stow is easy. > This certainly hasn't come up with Linux installs before, so I wonder > what is special about Stow, and what kind of problems it is trying to > solve that makes it important for me to deal with it. There are many things that can become popular because we did manage to make room for them, or (I'm not sure the idiom translates in English) because "we prepared the field". Autoconf and gettext are good examples, but there are a lot of tiny and humble things in this case, which have been prepared for a long time (and often after exhausting discussions :-), and then became of wider use. My feeling is that Stow is one of these things that is worth our favour, also given that once a package properly uses the Autoconf/Automake machinery, the extra effort needed for Stow support is small. I'm not saying it is important, but I think it is a good bet. -- François Pinard http://www.iro.umontreal.ca/~pinard From pinard@iro.umontreal.ca Tue Apr 4 05:22:02 2000 From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) Date: 04 Apr 2000 00:22:02 -0400 Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) In-Reply-To: Guido van Rossum's message of "Mon, 03 Apr 2000 23:05:11 -0400" References: <20000402205713.5F9041CDD6@dinsdale.python.org> <200004032304.TAA06405@eric.cnri.reston.va.us> <200004040305.XAA11241@eric.cnri.reston.va.us> Message-ID: Guido van Rossum writes: > I have to admit I am very naive about all the symbols that various vendors > (and GNU) require you to define in order to enable various variants of > their libraries and/or header files. I very well understand you, as I was in the same situation not very long ago, and to be honest, still am... I had to take a look at this to support `fnmatch' in Free `paxutils' (formerly GNU `tar'), which support has been excruciatingly difficult to get right. I'm not even sure we succeeded, but I'm not taking care of `tar' matters anymore. Another case of difficulty was trying to respond to all user requests about triggering ANSI compilation whenever the compiler supports it. For some sensitive systems, the mix of vendor symbols is extremely important to do correctly, before using their ANSI compilers. Moreover, for some vendors, header files are horribly broken, to the point we just gave up on ANSI compilation. > I was hoping that autoconf would do this -- but apparently it doesn't > or I must still tell it to. I also don't know what the typical downside > might be of turning on such symbols. I tried a lot of ways, and this is a sensitive matter on some systems. As I did not keep a copy of `tar' sources her, I cannot check what I finally did. But from memory, I think I managed to define _GNU_SOURCE to 1 if it was not defined, prior to including any system header file. Something like: #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif near the beginning of some strategic package header file. Most probably in `acconfig.h' for my things, followed by a @TOP@ line to make sure it gets copied in the generated `config.h'. If one uses `alloca', one is forced to include `config.h' very early in his C modules, so I took the habit of this early inclusion even when I do not use `alloca', making `config.h' a proper place. But I do not remember clearly, and checking in the few packages I still maintain, I do not use _GNU_SOURCE in them. I presume it worked because no vendors test for _GNU_SOURCE, besides Linux and, expectedly, the Hurd (which I do not run), or for source files extracted from the library of those systems, and included within other packages (surely not the case of Python :-). My pretesters did not report problems, but this is not a proof that none exist. On the other hand, `tar' was/is a good testbed for portability matters, as many people install it. -- François Pinard http://www.iro.umontreal.ca/~pinard From pinard@iro.umontreal.ca Tue Apr 4 05:20:54 2000 From: pinard@iro.umontreal.ca (pinard@iro.umontreal.ca) Date: Tue, 4 Apr 2000 00:20:54 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - installation report (PR#263) Message-ID: <20000404042054.2A3A21CEF7@dinsdale.python.org> Guido van Rossum writes: > I have to admit I am very naive about all the symbols that various vendors > (and GNU) require you to define in order to enable various variants of > their libraries and/or header files. I very well understand you, as I was in the same situation not very long ago, and to be honest, still am... I had to take a look at this to support `fnmatch' in Free `paxutils' (formerly GNU `tar'), which support has been excruciatingly difficult to get right. I'm not even sure we succeeded, but I'm not taking care of `tar' matters anymore. Another case of difficulty was trying to respond to all user requests about triggering ANSI compilation whenever the compiler supports it. For some sensitive systems, the mix of vendor symbols is extremely important to do correctly, before using their ANSI compilers. Moreover, for some vendors, header files are horribly broken, to the point we just gave up on ANSI compilation. > I was hoping that autoconf would do this -- but apparently it doesn't > or I must still tell it to. I also don't know what the typical downside > might be of turning on such symbols. I tried a lot of ways, and this is a sensitive matter on some systems. As I did not keep a copy of `tar' sources her, I cannot check what I finally did. But from memory, I think I managed to define _GNU_SOURCE to 1 if it was not defined, prior to including any system header file. Something like: #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif near the beginning of some strategic package header file. Most probably in `acconfig.h' for my things, followed by a @TOP@ line to make sure it gets copied in the generated `config.h'. If one uses `alloca', one is forced to include `config.h' very early in his C modules, so I took the habit of this early inclusion even when I do not use `alloca', making `config.h' a proper place. But I do not remember clearly, and checking in the few packages I still maintain, I do not use _GNU_SOURCE in them. I presume it worked because no vendors test for _GNU_SOURCE, besides Linux and, expectedly, the Hurd (which I do not run), or for source files extracted from the library of those systems, and included within other packages (surely not the case of Python :-). My pretesters did not report problems, but this is not a proof that none exist. On the other hand, `tar' was/is a good testbed for portability matters, as many people install it. -- François Pinard http://www.iro.umontreal.ca/~pinard From tim_one@email.msn.com Tue Apr 4 06:17:38 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 4 Apr 2000 01:17:38 -0400 (EDT) Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <20000404051738.1EBAB1CEB0@dinsdale.python.org> [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! From esr@thyrsus.com Tue Apr 4 13:23:00 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 4 Apr 2000 08:23:00 -0400 Subject: gpk@bell-labs.com: [Python-bugs-list] netrc module has bad error handling (PR#265) In-Reply-To: <20000404104919.22186.qmail@lannert.rz.uni-duesseldorf.de>; from lannert@lannert.rz.uni-duesseldorf.de on Tue, Apr 04, 2000 at 12:49:19PM +0200 References: <20000403192328.A4548@thyrsus.com> <20000404104919.22186.qmail@lannert.rz.uni-duesseldorf.de> Message-ID: <20000404082300.C6404@thyrsus.com> lannert@lannert.rz.uni-duesseldorf.de : > "Eric S. Raymond" wrote: > > > > BTW, the following lines: > > > > > > > > 31: lexer.whitepace = ' \t' > > > > 35: lexer.whitepace = ' \t\r\n' > > > > > > > > look a bit strange; shouldn't it be "whitespace" as defined in shlex? > > > > (But then, how did this ever work? :) > > > > This code is correct, though perhaps not as explicit as it should be. > > > > It is a workaround for the fact that macdefs actually have different > > lexical rules than the rest of the .netrc format. If you notice that > > the assignment on line 35 is actually restoring the shlex default I > > think you'll grok what's happening. > > > > It's kind of ugly, but that's not my fault :-). Go pound on whoever > > designed the .netrc format. > > I'm afraid I didn't make my point clear enough -- isn't "whitepace" a > misspelling for "whitespace"? If not, I'd suggest using a much > different name ... The workaround to cope with a strange file format > is certainly legitimate! ;-) Zounds. You're right, this can't have worked. I guess nobody has tried to parse macdefs yet! -- Eric S. Raymond Love your country, but never trust its government. -- Robert A. Heinlein. From Robin.Friedrich@pdq.net Tue Apr 4 15:20:35 2000 From: Robin.Friedrich@pdq.net (Robin.Friedrich@pdq.net) Date: Tue, 4 Apr 2000 10:20:35 -0400 (EDT) Subject: [Python-bugs-list] IDLE window close bug (PR#271) Message-ID: <20000404142035.D704E1CEFD@dinsdale.python.org> Full_Name: Robin Friedrich Version: 1.6b1 OS: Win95 Submission from: (NULL) (161.40.87.242) IDLE 0.6 included with 1.6B1 Click the window frame close icon (x) produces this on Win 95. PYTHONW caused an invalid page fault in module TK83.DLL at 016f:1001ba31. Registers: EAX=00623900 CS=016f EIP=1001ba31 EFLGS=00010206 EBX=00000000 SS=0177 ESP=0075f62c EBP=0075f630 ECX=00623900 DS=0177 ESI=00b38728 FS=507f EDX=00000000 ES=0177 EDI=00538794 GS=0000 Bytes at CS:EIP: 8b 82 d4 00 00 00 83 e0 02 85 c0 74 24 8b 4d fc Stack dump: 00623900 0000005a 00af88c9 00623900 00000001 00000000 005382d4 ffffffff ffffffff 00aecb7e 00aecb91 0040d590 00880aa0 00000000 00458610 00aa2be1 From les@infolabs.com Tue Apr 4 18:59:30 2000 From: les@infolabs.com (les@infolabs.com) Date: Tue, 4 Apr 2000 13:59:30 -0400 (EDT) Subject: [Python-bugs-list] libreadline problems (PR#272) Message-ID: <20000404175930.C2A111CD60@dinsdale.python.org> Full_Name: Les Johnson Version: 1.6a1 OS: Linux Submission from: morr0639.gti.net (208.216.122.39) Linux 2.2.14, GCC 2.95.2, glibc-2.0.112 Python-1.6a1 immediately dumps core when I start it with the readline module enabled. I'm using libreadline-4.1, and gdb tells me it's segfaulting in libc when it tries to flush stdout. I 'downgraded' to readline-2.2.1 and got it to work by forcing the readline module to link with the static libreadline.a but it won't link to the dynamic libreadline.so. Same thing with today's CVS source (April 4). I strongly suspect the libreadline-4.1 problems are related to threads, but I can't figure out the 2.2.1 linking problem: gcc -shared readline.o -lreadline -ltermcap -o readline.so /usr/local/lib/libreadline.so: In function `tilde_expand_word': /home/les/readline-2.2.1/tilde.c:386: multiple definition of `_DYNAMIC' /usr/lib/crti.o(.dynamic+0x0): first defined here /usr/local/lib/libreadline.so: In function `tilde_expand_word': /home/les/readline-2.2.1/tilde.c:386: multiple definition of `_GLOBAL_OFFSET_TAB LE_' /usr/lib/crti.o(.got.plt+0x0): first defined here /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: readline.so: undefined versioned symbol name __ctype_tolower@@GLIBC _2.0 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status From skip@mojam.com Tue Apr 4 21:06:10 2000 From: skip@mojam.com (skip@mojam.com) Date: Tue, 4 Apr 2000 16:06:10 -0400 (EDT) Subject: [Python-bugs-list] mimetools.{encode,decode} should handle trivial encodings (PR#273) Message-ID: <20000404200610.814481CD9F@dinsdale.python.org> Full_Name: Skip Montanaro Version: 1.5.2+/1.6a1 OS: Linux Submission from: beluga.mojam.com (199.249.165.173) mimetools.{encode,decode} handle a number of different content transer encodings, but don't handle trivial encodings like 7bit and 8bit. It seems to me that it would simplify callers' code if these functions handled these common cases. For example, a loop over a MultiFile object code be coded as file = multifile.MultiFile(sys.stdin) file.push(boundary) while file.next(): submessage = mimetools.Message(file) try: data = mimetools.decode(file.read(), submessage.getencoding()) except ValueError: print "unknown encoding:", submessage.getencoding() continue process_data(data) file.pop() with the expectation that hitting "except ValueError" would actually be exceptional. Because 7bit and 8bit encodings are not currently handled, all calling code has to handle the relatively common (and trivial) cases. Here's a patch that just does a noop for encoding and decoding 7bit/8bit data. *** /tmp/mimetools.py.~1.16~qKA6Tr Tue Apr 4 13:16:41 2000 --- /tmp/mimetools.pyqKAHex Tue Apr 4 13:16:41 2000 *************** *** 140,145 **** --- 140,147 ---- if encoding in ('uuencode', 'x-uuencode', 'uue', 'x-uue'): import uu return uu.decode(input, output) + if encoding in ('7bit', '8bit'): + output.write(input.read()) if decodetab.has_key(encoding): pipethrough(input, decodetab[encoding], output) else: *************** *** 157,162 **** --- 159,166 ---- if encoding in ('uuencode', 'x-uuencode', 'uue', 'x-uue'): import uu return uu.encode(input, output) + if encoding in ('7bit', '8bit'): + output.write(input.read()) if encodetab.has_key(encoding): pipethrough(input, encodetab[encoding], output) else: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Skip Montanaro skip@mojam.com From guido@python.org Tue Apr 4 21:10:46 2000 From: guido@python.org (guido@python.org) Date: Tue, 4 Apr 2000 16:10:46 -0400 (EDT) Subject: [Python-bugs-list] libreadline problems (PR#272) Message-ID: <20000404201046.9F1D01CD94@dinsdale.python.org> > Full_Name: Les Johnson > Version: 1.6a1 > OS: Linux > Submission from: morr0639.gti.net (208.216.122.39) > > > Linux 2.2.14, GCC 2.95.2, glibc-2.0.112 > > Python-1.6a1 immediately dumps core when I start it with the readline module > enabled. I'm using libreadline-4.1, and gdb tells me it's segfaulting in > libc when it tries to flush stdout. I 'downgraded' to readline-2.2.1 and got > it to work by forcing the readline module to link with the static libreadline.a > but it won't link to the dynamic libreadline.so. Same thing with today's CVS > source (April 4). > > I strongly suspect the libreadline-4.1 problems are related to threads, but I > can't figure out the 2.2.1 linking problem: > > gcc -shared readline.o -lreadline -ltermcap -o readline.so > /usr/local/lib/libreadline.so: In function `tilde_expand_word': > /home/les/readline-2.2.1/tilde.c:386: multiple definition of `_DYNAMIC' > /usr/lib/crti.o(.dynamic+0x0): first defined here > /usr/local/lib/libreadline.so: In function `tilde_expand_word': > /home/les/readline-2.2.1/tilde.c:386: multiple definition of > `_GLOBAL_OFFSET_TAB > LE_' > /usr/lib/crti.o(.got.plt+0x0): first defined here > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: readline.so: undefined versioned symbol name > __ctype_tolower@@GLIBC > _2.0 > /usr/bin/ld: failed to set dynamic section sizes: Bad value > collect2: ld returned 1 exit status Seems like a bug in /usr/bin/ld to me... Not much else I can do about this here. Try bouncing this off the binutils support list? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Apr 4 21:51:13 2000 From: guido@python.org (guido@python.org) Date: Tue, 4 Apr 2000 16:51:13 -0400 (EDT) Subject: [Python-bugs-list] mimetools.{encode,decode} should handle trivial encodings (PR#273) Message-ID: <20000404205113.E58EB1CDAD@dinsdale.python.org> Thanks -- good suggestion. Checked in now. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Apr 5 15:35:35 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 05 Apr 2000 10:35:35 -0400 Subject: gpk@bell-labs.com: [Python-bugs-list] netrc module has bad error handling (PR#265) In-Reply-To: Your message of "Wed, 05 Apr 0100 13:45:09 +0200." <20000405114509.23669.qmail@lannert.rz.uni-duesseldorf.de> References: <20000405114509.23669.qmail@lannert.rz.uni-duesseldorf.de> Message-ID: <200004051435.KAA16262@eric.cnri.reston.va.us> Detlef, if you want this added to the Python distribution, please consider the patch guidelines at www.python.org/patches/. Also, in this case, I'd prefer to receive Eric's consent, as I don't understand the netrc.py code at all myself... :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From Ann_roemaet@hotmail.com Wed Apr 5 15:47:59 2000 From: Ann_roemaet@hotmail.com (Ann_roemaet@hotmail.com) Date: Wed, 5 Apr 2000 10:47:59 -0400 (EDT) Subject: [Python-bugs-list] Problem printing in word 2000 (PR#274) Message-ID: <20000405144759.B44621CE0F@dinsdale.python.org> Full_Name: Ann Roemaet Version: OS: Windows 98 Submission from: castor.telenet-ops.be (195.130.132.52) Hi there! As I am working on a helpdesk, I have lots of people confronting me with the same problem. The moment they want to print in Word 2000 in landscape, their system hangs... We already found a work-around, by making landscape the default setting in their printer settings, and after printing put it back to portrait. Afcourse this is not really what we are looking for, we want a sollution, not a work-around. Does anybody of you already had this problem or a sollution for this? Thank you very much! Kind regards, Ann Roemaet From guido@python.org Wed Apr 5 16:22:07 2000 From: guido@python.org (guido@python.org) Date: Wed, 5 Apr 2000 11:22:07 -0400 (EDT) Subject: [Python-bugs-list] Problem printing in word 2000 (PR#274) Message-ID: <20000405152207.D84C71CE1F@dinsdale.python.org> > As I am working on a helpdesk, I have lots of people confronting me with the > same problem. > The moment they want to print in Word 2000 in landscape, their system hangs... > We already found a work-around, by making landscape the default setting in their > > printer settings, and after printing put it back to portrait. > Afcourse this is not really what we are looking for, we want a sollution, not a > work-around. > Does anybody of you already had this problem or a sollution for this? What does this have to do with Python? --Guido van Rossum (home page: http://www.python.org/~guido/) From louisbl@earthlink.com Wed Apr 5 19:23:47 2000 From: louisbl@earthlink.com (louisbl@earthlink.com) Date: Wed, 5 Apr 2000 14:23:47 -0400 (EDT) Subject: [Python-bugs-list] importing extensions (PR#275) Message-ID: <20000405182347.B19231CE03@dinsdale.python.org> Full_Name: Louis Lancton Version: python1.6a1 OS: Windows Submission from: 1cust158.tnt1.college-station.tx.da.uu.net (63.23.193.158) I installed python-1.6a1 (Windows) and found that I couldn't import any extensions. That blew wxPython as well as calldll.pyd, avl.pyd and a couple I wrote myself. I should have tried Numeric but I'm back to 152 now. Got "abnormal program termination" on any such attempt. From guido@python.org Wed Apr 5 19:26:15 2000 From: guido@python.org (guido@python.org) Date: Wed, 5 Apr 2000 14:26:15 -0400 (EDT) Subject: [Python-bugs-list] importing extensions (PR#275) Message-ID: <20000405182615.646D41CE53@dinsdale.python.org> > I installed python-1.6a1 (Windows) and > found that I couldn't import any extensions. > That blew wxPython as well as calldll.pyd, > avl.pyd and a couple I wrote myself. I should > have tried Numeric but I'm back to 152 now. > Got "abnormal program termination" on any such > attempt. Thanks for reporting this. It is probably necessary that all extensions be recompiled for Python 1.6 (it's sufficiently different to warrant this). But "abnormal program termination" is a particularly harsh response -- I'll see if we can improve the diagnostics somewhat! --Guido van Rossum (home page: http://www.python.org/~guido/) From kwel@ieee.org Wed Apr 5 20:16:57 2000 From: kwel@ieee.org (kwel@ieee.org) Date: Wed, 5 Apr 2000 15:16:57 -0400 (EDT) Subject: [Python-bugs-list] Hexadecimal to specify char in string literal (PR#276) Message-ID: <20000405191657.113F01CE44@dinsdale.python.org> Full_Name: Kurt Welgehausen Version: 1.5.2 OS: Linux (Intel) & BeOS (PPC) Submission from: cleve-37.brokersys.com (206.180.156.38) After s = 'abc\x09def' s has the value 'abc\xef' == 'abc\357'. In fact, it appears that you can put as many hex chars ([0-9a-f]) as you want between the 'x' and the final 'ef', and you will get the same result. (Hard to believe that this has not been reported, but I can't find it on python.org or deja.) From guido@python.org Wed Apr 5 20:40:00 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 05 Apr 2000 15:40:00 -0400 Subject: [Python-bugs-list] Hexadecimal to specify char in string literal (PR#276) In-Reply-To: Your message of "Wed, 05 Apr 2000 15:16:57 EDT." <20000405191657.113F01CE44@dinsdale.python.org> References: <20000405191657.113F01CE44@dinsdale.python.org> Message-ID: <200004051940.PAA17094@eric.cnri.reston.va.us> > After > > s = 'abc\x09def' > > s has the value 'abc\xef' == 'abc\357'. > > In fact, it appears that you can put as many hex chars ([0-9a-f]) > as you want between the 'x' and the final 'ef', and you will get > the same result. > > (Hard to believe that this has not been reported, but I can't find > it on python.org or deja.) This is not a bug. It is how the \x escape is defined in ANSI C and I just copied it from there. It is also documented. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Apr 5 20:37:40 2000 From: guido@python.org (guido@python.org) Date: Wed, 5 Apr 2000 15:37:40 -0400 (EDT) Subject: [Python-bugs-list] Hexadecimal to specify char in string literal (PR#276) Message-ID: <20000405193740.569D41CE35@dinsdale.python.org> > After > > s = 'abc\x09def' > > s has the value 'abc\xef' == 'abc\357'. > > In fact, it appears that you can put as many hex chars ([0-9a-f]) > as you want between the 'x' and the final 'ef', and you will get > the same result. > > (Hard to believe that this has not been reported, but I can't find > it on python.org or deja.) This is not a bug. It is how the \x escape is defined in ANSI C and I just copied it from there. It is also documented. --Guido van Rossum (home page: http://www.python.org/~guido/) From gellsmore@yahoo.com Wed Apr 5 22:00:11 2000 From: gellsmore@yahoo.com (gellsmore@yahoo.com) Date: Wed, 5 Apr 2000 17:00:11 -0400 (EDT) Subject: [Python-bugs-list] Floating point numbers (PR#277) Message-ID: <20000405210011.EE5121CE2F@dinsdale.python.org> Full_Name: Graham Ellsmore Version: Python CE 1.0b1 OS: Windows CE H/PC 3.01 pro Submission from: 128.04-03.quay.dial.plus.net.uk (212.159.75.128) Floating point answer objects not returned correctly >>>3.1 g All floats return g but will work in scenario below where floats form part of the expression but not the answer object >>>int(3.1/2) 1 this works. From mhammond@skippinet.com.au Thu Apr 6 00:48:26 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 6 Apr 2000 09:48:26 +1000 Subject: [Python-bugs-list] importing extensions (PR#275) In-Reply-To: <20000405182615.646D41CE53@dinsdale.python.org> Message-ID: I can not think of a good way to prevent this error. Problem is: * Python.exe correctly loads Python16.dll * Python does import foo.pyd * Loading foo.pyd forces Python15.dll to be loaded. * Python15.dll crashes as it has not been initialized. I can not see a good solution to this, other than a fairly heavy solution, and even then it would only work for 1.6 vs 1.7 - ie, we would also need some diagnostic code in the _early_ version to handle this gracefully. What this means is, if we want to prevent this same problem in Python 1.7 vs Python 1.6, we need to add the code into 1.6. It is too late for 1.5. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > guido@python.org > Sent: Thursday, 6 April 2000 4:26 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: Re: [Python-bugs-list] importing extensions (PR#275) > > > > I installed python-1.6a1 (Windows) and > > found that I couldn't import any extensions. > > That blew wxPython as well as calldll.pyd, > > avl.pyd and a couple I wrote myself. I should > > have tried Numeric but I'm back to 152 now. > > Got "abnormal program termination" on any such > > attempt. > > Thanks for reporting this. It is probably necessary that all > extensions be recompiled for Python 1.6 (it's > sufficiently different > to warrant this). But "abnormal program termination" is a > particularly harsh response -- I'll see if we can improve the > diagnostics somewhat! > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mhammond@skippinet.com.au Thu Apr 6 00:56:15 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 6 Apr 2000 09:56:15 +1000 Subject: FW: [Python-bugs-list] Floating point numbers (PR#277) Message-ID: Actually, this works correctly for me on my Cassiopeia E11. However, the Windows CE work is not particularly active at the moment. I have CC'd this message to the Windows CE mailing list where most of the developers and users can be found. Maybe someone else with similar hardware can repro it. This list is probably the best place to discuss Windows CE issues - in a number of cases, the Windows CE sources have not been folded back into the core Python sources, so the Python bugs list hasnt a clue what to do with these reports. The info on the mailing list can be found at http://www.egroups.com/list/python-ce/ Mark. -----Original Message----- From: python-bugs-list-admin@python.org [mailto:python-bugs-list-admin@python.org]On Behalf Of gellsmore@yahoo.com Sent: Thursday, 6 April 2000 7:00 AM To: python-bugs-list@python.org Cc: bugs-py@python.org Subject: [Python-bugs-list] Floating point numbers (PR#277) Full_Name: Graham Ellsmore Version: Python CE 1.0b1 OS: Windows CE H/PC 3.01 pro Submission from: 128.04-03.quay.dial.plus.net.uk (212.159.75.128) Floating point answer objects not returned correctly >>>3.1 g All floats return g but will work in scenario below where floats form part of the expression but not the answer object >>>int(3.1/2) 1 this works. _______________________________________________ Python-bugs-list maillist - Python-bugs-list@python.org http://www.python.org/mailman/listinfo/python-bugs-list From guido@python.org Thu Apr 6 14:41:45 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 06 Apr 2000 09:41:45 -0400 Subject: [Python-bugs-list] importing extensions (PR#275) In-Reply-To: Your message of "Thu, 06 Apr 2000 09:48:26 +1000." References: Message-ID: <200004061341.JAA23956@eric.cnri.reston.va.us> > Problem is: > * Python.exe correctly loads Python16.dll > * Python does import foo.pyd > * Loading foo.pyd forces Python15.dll to be loaded. > * Python15.dll crashes as it has not been initialized. > > I can not see a good solution to this, other than a fairly heavy > solution, and even then it would only work for 1.6 vs 1.7 - ie, we > would also need some diagnostic code in the _early_ version to > handle this gracefully. > > What this means is, if we want to prevent this same problem in > Python 1.7 vs Python 1.6, we need to add the code into 1.6. It is > too late for 1.5. Is it really a problem? Can't we just say "extensions are incompatible between versions"? Would there be a way to discover before loading a DLL that it links with python15.dll and then refuse to do it? I'd gladly accept patches for dynload_win.c to do this... --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond@skippinet.com.au Thu Apr 6 14:45:37 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 6 Apr 2000 23:45:37 +1000 Subject: [Python-bugs-list] importing extensions (PR#275) In-Reply-To: <200004061341.JAA23956@eric.cnri.reston.va.us> Message-ID: > Is it really a problem? Can't we just say "extensions are > incompatible between versions"? Sure - I was happy with that! I was just responding to the bug report :-) > Would there be a way to discover before loading a DLL > that it links > with python15.dll and then refuse to do it? I'd gladly > accept patches > for dynload_win.c to do this... So would I - and if you dont see it as a pressing need, let's just leave it at that :-) Mark. From les@infolabs.com Thu Apr 6 15:55:54 2000 From: les@infolabs.com (les@infolabs.com) Date: Thu, 6 Apr 2000 10:55:54 -0400 (EDT) Subject: [Python-bugs-list] libreadline problems (PR#272) Message-ID: <20000406145554.5BC3F1CE7C@dinsdale.python.org> I originally wrote: >> Linux 2.2.14, GCC 2.95.2, glibc-2.0.112 >> >> Python-1.6a1 immediately dumps core when I start it with the readline module >> enabled. I'm using libreadline-4.1, and gdb tells me it's segfaulting in >> libc when it tries to flush stdout. ...and Guido replied: > Seems like a bug in /usr/bin/ld to me... Not much else I can do about > this here. Try bouncing this off the binutils support list? Not a bug in /usr/bin/ld, but I resolved this one by upgrading from glibc2.0.112 to glibc2.1.3. No more core dumps, and readline works fine. Thanks! - Les Johnson From pinard@iro.umontreal.ca Thu Apr 6 16:09:24 2000 From: pinard@iro.umontreal.ca (pinard@iro.umontreal.ca) Date: Thu, 6 Apr 2000 11:09:24 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - Poor diagnostic (PR#278) Message-ID: <20000406150924.3D75B1CE7E@dinsdale.python.org> Hello. This might be seen as a limitation, rather than a bug. This is not specific to 1.6a1, as 1.5.2 shows the same. Executing a Python script yields: Traceback (most recent call last): File "./to-html", line 26, in ? import data, htmlpage, localweb, registry SyntaxError: non-keyword arg after keyword arg (line 26) There is such an error in file `../lib/htmlpage.py' here, so the diagnostic is proper. However, a mere `(line 26)' does not hint about which of the four imported sources has the error. As a way around the poor diagnostic, you might suggest that I avoid bundling many imports on one line. This would help of course, but I still think Python could do better, here. -- François Pinard http://www.iro.umontreal.ca/~pinard From tim_one@email.msn.com Fri Apr 7 05:36:47 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Fri, 7 Apr 2000 00:36:47 -0400 (EDT) Subject: [Python-bugs-list] 1.6a1 regression in string.atol (PR#279) Message-ID: <20000407043647.64FB81CD69@dinsdale.python.org> Full_Name: Tim Peters Version: 1.6a1 OS: Win95 Submission from: 1cust99.tnt4.bos1.da.uu.net (63.21.45.99) Here's 1.5.2: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import string >>> string.atol("45.67", 10) Traceback (innermost last): File "", line 1, in ? ValueError: invalid literal for atol(): 45.67 >>> Here's 1.6a1: D:\Python>\python-1.6\python Python 1.6a1 (#0, Mar 30 2000, 16:30:28) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import string >>> string.atol("45.67", 10) 45L >>> 1.5.2 behavior is correct. "int" and "long" are OK here in both. string.atoi and string.atol are OK here in both too *provided* that an explicit base argument isn't given. string.atoi is OK regardless. So the regression appears specific to string.atol with an explicit base argument. From lk@pdi.com Fri Apr 7 07:21:44 2000 From: lk@pdi.com (lk@pdi.com) Date: Fri, 7 Apr 2000 02:21:44 -0400 (EDT) Subject: [Python-bugs-list] Bad default value to constructor in Lib/fileinput.py (PR#280) Message-ID: <20000407062144.D19791CD69@dinsdale.python.org> Full_Name: Lawrence Kesteloot Version: 1.5.2 OS: Linux Submission from: dynamic37.pm02.sf3d.best.com (209.24.234.101) In the Lib/fileinput.py module, the default value for the list of files is (), an empty tuple. This means that the function cannot distinguish between being passed nothing (meaning use sys.argv) and an empty list. If the function is passed an empty list, it should use stdin, not revert to sys.argv! This use of fileinput may have nothing to do with sys.argv, and it's extremely weird to pass an empty list and find that sys.argv is being used. For example, I may want to have two parameters followed by a possibly-empty list of files. (Empty would be stdin.) foo1 = sys.argv[1] foo2 = sys.argv[2] for line in fileinput.input(argv[3:]) ... But in the above code, if no files are specified, then the first two arguments will be used for filenames. This is really bad and never what the user wants. Instead of using () as the default value, use None. Replacing the top of the constructor with this works for me: if type(files) == type(''): files = (files,) else: if files is None: files = tuple(sys.argv[1:]) else: files = tuple(files) if not files: files = ('-',) print files And change the default values of "files" in both the constructor and the global input() function to None. I suspect that this is a safe change, because I can't imagine someone actively passing in an empty list when they want sys.argv used. Thanks, Lawrence From larsga@garshol.priv.no Fri Apr 7 08:47:38 2000 From: larsga@garshol.priv.no (larsga@garshol.priv.no) Date: Fri, 7 Apr 2000 03:47:38 -0400 (EDT) Subject: [Python-bugs-list] Unicode and % operator (PR#281) Message-ID: <20000407074738.7E8F61CD07@dinsdale.python.org> Full_Name: Lars Marius Garshol Version: 1.6a1 OS: Linux Submission from: epsilon.opera.no (195.0.254.101) It seems that when doing 'a % b' where a is a normal string and b is a Unicode string, the result will be a normal string where b appears UTF-8-encoded. IMHO this is the Wrong Thing, since Unicode strings should always appear as Unicode unless the code explicitly requests something else. Also, this differs from the behaviour of the corresponding approach using +. The interpreter dialog below should explain. [larsga@lambda Python-1.6a1]$ ./python Python 1.6a1 (#1, Apr 7 2000, 09:29:32) [GCC 2.8.1] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> s1 = unichr(4312) >>> s1 u'\u10D8' >>> s2 = "This is a " >>> s3 = " text" >>> s2 + s1 + s3 u'This is a \u10D8 text' >>> "This is a %s text" % s1 'This is a \341\203\230 text' >>> u"This is a %s text" % s1 u'This is a \u10D8 text' >>> From mal@lemburg.com Fri Apr 7 09:49:59 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Apr 2000 10:49:59 +0200 Subject: [Python-bugs-list] 1.6a1 regression in string.atol (PR#279) References: <20000407043647.64FB81CD69@dinsdale.python.org> Message-ID: <38EDA137.83B7184A@lemburg.com> tim_one@email.msn.com wrote: > > Full_Name: Tim Peters > Version: 1.6a1 > OS: Win95 > Submission from: 1cust99.tnt4.bos1.da.uu.net (63.21.45.99) > > Here's 1.5.2: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import string > >>> string.atol("45.67", 10) > Traceback (innermost last): > File "", line 1, in ? > ValueError: invalid literal for atol(): 45.67 > >>> > > Here's 1.6a1: > > D:\Python>\python-1.6\python > Python 1.6a1 (#0, Mar 30 2000, 16:30:28) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import string > >>> string.atol("45.67", 10) > 45L > >>> > > 1.5.2 behavior is correct. "int" and "long" are OK here in both. string.atoi > and string.atol are OK here in both too *provided* that an explicit base > argument isn't given. string.atoi is OK regardless. So the regression appears > specific to string.atol with an explicit base argument. Do you have the latest CVS version installed ? I get the following results: >>> string.atol('45.67') Traceback (most recent call last): File "", line 1, in ? File "./Lib/string.py", line 230, in atol return _long(s, base) ValueError: invalid literal for long(): 45.67 >>> string.atol('45.67',10) Traceback (most recent call last): File "", line 1, in ? File "./Lib/string.py", line 230, in atol return _long(s, base) ValueError: invalid literal for long(): 45.67 >>> long('45.67') Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for long(): 45.67 >>> long('45.67',10) Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for long(): 45.67 -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Apr 7 11:18:23 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Fri, 7 Apr 2000 06:18:23 -0400 (EDT) Subject: [Python-bugs-list] 1.6a1 regression in string.atol (PR#279) Message-ID: <20000407101823.AEB231CD26@dinsdale.python.org> tim_one@email.msn.com wrote: > > Full_Name: Tim Peters > Version: 1.6a1 > OS: Win95 > Submission from: 1cust99.tnt4.bos1.da.uu.net (63.21.45.99) > > Here's 1.5.2: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import string > >>> string.atol("45.67", 10) > Traceback (innermost last): > File "", line 1, in ? > ValueError: invalid literal for atol(): 45.67 > >>> > > Here's 1.6a1: > > D:\Python>\python-1.6\python > Python 1.6a1 (#0, Mar 30 2000, 16:30:28) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import string > >>> string.atol("45.67", 10) > 45L > >>> > > 1.5.2 behavior is correct. "int" and "long" are OK here in both. string.atoi > and string.atol are OK here in both too *provided* that an explicit base > argument isn't given. string.atoi is OK regardless. So the regression appears > specific to string.atol with an explicit base argument. Do you have the latest CVS version installed ? I get the following results: >>> string.atol('45.67') Traceback (most recent call last): File "", line 1, in ? File "./Lib/string.py", line 230, in atol return _long(s, base) ValueError: invalid literal for long(): 45.67 >>> string.atol('45.67',10) Traceback (most recent call last): File "", line 1, in ? File "./Lib/string.py", line 230, in atol return _long(s, base) ValueError: invalid literal for long(): 45.67 >>> long('45.67') Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for long(): 45.67 >>> long('45.67',10) Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for long(): 45.67 -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Apr 7 11:05:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Apr 2000 12:05:50 +0200 Subject: [Python-bugs-list] Unicode and % operator (PR#281) References: <20000407074738.7E8F61CD07@dinsdale.python.org> Message-ID: <38EDB2FE.AC482B39@lemburg.com> larsga@garshol.priv.no wrote: > > Full_Name: Lars Marius Garshol > Version: 1.6a1 > OS: Linux > Submission from: epsilon.opera.no (195.0.254.101) > > It seems that when doing 'a % b' where a is a normal string and b is a > Unicode string, the result will be a normal string where b appears > UTF-8-encoded. IMHO this is the Wrong Thing, since Unicode strings should > always appear as Unicode unless the code explicitly requests something > else. > > Also, this differs from the behaviour of the corresponding approach using > +. > > The interpreter dialog below should explain. > > [larsga@lambda Python-1.6a1]$ ./python > Python 1.6a1 (#1, Apr 7 2000, 09:29:32) [GCC 2.8.1] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> s1 = unichr(4312) > >>> s1 > u'\u10D8' > >>> s2 = "This is a " > >>> s3 = " text" > >>> s2 + s1 + s3 > u'This is a \u10D8 text' > >>> "This is a %s text" % s1 > 'This is a \341\203\230 text' > >>> u"This is a %s text" % s1 > u'This is a \u10D8 text' > >>> Thanks for noticing this one... it will be fixed in the next alpha round. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Apr 7 11:18:37 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Fri, 7 Apr 2000 06:18:37 -0400 (EDT) Subject: [Python-bugs-list] Unicode and % operator (PR#281) Message-ID: <20000407101837.C32471CD37@dinsdale.python.org> larsga@garshol.priv.no wrote: > > Full_Name: Lars Marius Garshol > Version: 1.6a1 > OS: Linux > Submission from: epsilon.opera.no (195.0.254.101) > > It seems that when doing 'a % b' where a is a normal string and b is a > Unicode string, the result will be a normal string where b appears > UTF-8-encoded. IMHO this is the Wrong Thing, since Unicode strings should > always appear as Unicode unless the code explicitly requests something > else. > > Also, this differs from the behaviour of the corresponding approach using > +. > > The interpreter dialog below should explain. > > [larsga@lambda Python-1.6a1]$ ./python > Python 1.6a1 (#1, Apr 7 2000, 09:29:32) [GCC 2.8.1] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> s1 = unichr(4312) > >>> s1 > u'\u10D8' > >>> s2 = "This is a " > >>> s3 = " text" > >>> s2 + s1 + s3 > u'This is a \u10D8 text' > >>> "This is a %s text" % s1 > 'This is a \341\203\230 text' > >>> u"This is a %s text" % s1 > u'This is a \u10D8 text' > >>> Thanks for noticing this one... it will be fixed in the next alpha round. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@python.org Fri Apr 7 14:18:08 2000 From: guido@python.org (guido@python.org) Date: Fri, 7 Apr 2000 09:18:08 -0400 (EDT) Subject: [Python-bugs-list] Bad default value to constructor in Lib/fileinput.py (PR#280) Message-ID: <20000407131808.9D64F1CD7D@dinsdale.python.org> > Full_Name: Lawrence Kesteloot > Version: 1.5.2 > OS: Linux > Submission from: dynamic37.pm02.sf3d.best.com (209.24.234.101) > > In the Lib/fileinput.py module, the default value for the list > of files is (), an empty tuple. This means that the function > cannot distinguish between being passed nothing (meaning use > sys.argv) and an empty list. If the function is passed an empty > list, it should use stdin, not revert to sys.argv! This use > of fileinput may have nothing to do with sys.argv, and it's > extremely weird to pass an empty list and find that sys.argv > is being used. > > For example, I may want to have two parameters followed by > a possibly-empty list of files. (Empty would be stdin.) > > foo1 = sys.argv[1] > foo2 = sys.argv[2] > for line in fileinput.input(argv[3:]) > ... > > But in the above code, if no files are specified, then the > first two arguments will be used for filenames. This is > really bad and never what the user wants. > > Instead of using () as the default value, use None. Replacing > the top of the constructor with this works for me: > > if type(files) == type(''): > files = (files,) > else: > if files is None: > files = tuple(sys.argv[1:]) > else: > files = tuple(files) > if not files: > files = ('-',) > print files > > And change the default values of "files" in both the > constructor and the global input() function to None. > > I suspect that this is a safe change, because I can't > imagine someone actively passing in an empty list when > they want sys.argv used. Very good! This also fixes a bug in the current test harness (for which a much less elegant fix was just submitted). --Guido van Rossum (home page: http://www.python.org/~guido/) From gpk@bell-labs.com Sun Apr 9 03:51:04 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Sat, 8 Apr 2000 22:51:04 -0400 (EDT) Subject: [Python-bugs-list] Error in dictionary comparison (PR#282) Message-ID: <20000409025104.1B2D81CDD1@dinsdale.python.org> Full_Name: Greg Kochanski Version: 1.5.2 OS: Solaris 2.6 Submission from: h-135-104-50-27.research.bell-labs.com (135.104.50.27) # The following little chunk of python seems to reveal # a bug in dictionary comparison or construction. # # As can be seen in the printout, the list of keys are # the same (after sorting). All the values are one. # Thus, the two dictionaries ought to compare equal. # They don't. # # Smaller chunks of code don't seem to reveal the problem. # python bug.py # a.d= {10: 1, 4: 1, 3: 1, 2: 1, 11: 1} [2, 3, 4, 10, 11] # b.d= {10: 1, 4: 1, 3: 1, 2: 1, 11: 1} [2, 3, 4, 10, 11] # Traceback (innermost last): # File "bug.py", line 34, in ? # test() # File "bug.py", line 30, in test # assert equals(Set([2, 4, 3, 11, 10]), Set([2, 3, 4, 10, 11])) # AssertionError _dicttype = type({}) class Set: def __init__(self, a = []): if type(a) == _dicttype or type(a) == type(self): self.d = a.copy() else: self.d = {} for t in a: self.add(t) def add(self, item): self.d[item] = 1 def copy(self): return Set(self.d) def equals(a, b): ad = a.d.keys() ad.sort() print "a.d=", a.d, ad bd = b.d.keys() bd.sort() print "b.d=", b.d, bd return Set(b).d == Set(a).d def test(): assert equals(Set([2, 4, 3, 11, 10]), Set([2, 3, 4, 10, 11])) if __name__ == '__main__': test() From tim_one@email.msn.com Sun Apr 9 05:39:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Apr 2000 00:39:05 -0400 Subject: [Python-bugs-list] 1.6a1 regression in string.atol (PR#279) In-Reply-To: <38EDA137.83B7184A@lemburg.com> Message-ID: <000001bfa1dd$8a209a20$172d153f@tim> [MAL] > Do you have the latest CVS version installed ? The bug report was against the released 1.6a1. As to the CVS version, the MS project file has gotten so involved (subsuming 14 "projects" + assorted variations of each) I'm really not sure what I'm building under Windows anymore. My best guess as to what might be 1.6 does indeed not show the error. So, *maybe* it's fixed . If I were a betting man, I'd say it is. Close the bug! From tim_one@email.msn.com Sun Apr 9 05:36:40 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Sun, 9 Apr 2000 00:36:40 -0400 (EDT) Subject: [Python-bugs-list] 1.6a1 regression in string.atol (PR#279) Message-ID: <20000409043640.BC51F1CDD8@dinsdale.python.org> [MAL] > Do you have the latest CVS version installed ? The bug report was against the released 1.6a1. As to the CVS version, the MS project file has gotten so involved (subsuming 14 "projects" + assorted variations of each) I'm really not sure what I'm building under Windows anymore. My best guess as to what might be 1.6 does indeed not show the error. So, *maybe* it's fixed . If I were a betting man, I'd say it is. Close the bug! From tim_one@email.msn.com Sun Apr 9 06:10:14 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Apr 2000 01:10:14 -0400 Subject: [Python-bugs-list] Error in dictionary comparison (PR#282) In-Reply-To: <20000409025104.1B2D81CDD1@dinsdale.python.org> Message-ID: <000501bfa1e1$e50e5ae0$172d153f@tim> [gpk@bell-labs.com] This isn't a Python bug. Plug in this variant of your equals() function to see where you're getting off track: def equals(a, b): assert a.d == b.d # Note that this succeeds! ad = a.d.keys() ad.sort() print "a.d=", a.d, ad bd = b.d.keys() bd.sort() print "b.d=", b.d, bd x, y = Set(b).d, Set(a).d print x, y # Note that these aren't what you think return Set(b).d == Set(a).d From tim_one@email.msn.com Sun Apr 9 06:07:53 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Sun, 9 Apr 2000 01:07:53 -0400 (EDT) Subject: [Python-bugs-list] Error in dictionary comparison (PR#282) Message-ID: <20000409050753.6BA491CDDB@dinsdale.python.org> [gpk@bell-labs.com] This isn't a Python bug. Plug in this variant of your equals() function to see where you're getting off track: def equals(a, b): assert a.d == b.d # Note that this succeeds! ad = a.d.keys() ad.sort() print "a.d=", a.d, ad bd = b.d.keys() bd.sort() print "b.d=", b.d, bd x, y = Set(b).d, Set(a).d print x, y # Note that these aren't what you think return Set(b).d == Set(a).d From musingattheruins@yahoo.com Mon Apr 10 17:30:45 2000 From: musingattheruins@yahoo.com (musingattheruins@yahoo.com) Date: Mon, 10 Apr 2000 12:30:45 -0400 (EDT) Subject: [Python-bugs-list] Debugger (win and idle) (PR#283) Message-ID: <20000410163045.99D8B1CD29@dinsdale.python.org> Full_Name: Bill Mailloux Version: 1.5.2 OS: Win32 Submission from: (NULL) (216.91.23.226) The python debugger (both Idle and PythonWin) does not undertand packages. Can run scripts from the command line that cannot be run in the debugger... Create package 'Test' in the directory "My Modules", add an __init__.py (empty) to the directory "My modules\Test", create file testfile.py with the contents... class TheTest: def __init__(self): self.i = 1 def go(self): return self.i Add the path to the Python path with the following file (test.reg)... REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\1.5\PythonPath\TheTest] @="C:\\My modules" then try the following at the python prompt: import Test.testfile j = Test.testfile.TheTest() k = j.go runs fine right? Yes it does, now step through it in the debugger and you get... import Test.testfile j = Test.testfile.TheTest() #exception: attribute 'TheTest' k = j.go Does not appear to be realted to the class (you can change it to a 'function in a module' instead of a 'method in a class in a module' and you get the a similar result.) Debugger does not understand packages. From kessler@ccdc.cam.ac.uk Mon Apr 10 18:32:31 2000 From: kessler@ccdc.cam.ac.uk (kessler@ccdc.cam.ac.uk) Date: Mon, 10 Apr 2000 13:32:31 -0400 (EDT) Subject: [Python-bugs-list] CR/LF line endings in _sre.c sre.h sre_constants.h (PR#284) Message-ID: <20000410173231.4CCE11CD47@dinsdale.python.org> Full_Name: Magnus Kessler Version: 1.6a (10.04.2000) OS: Irix 6.3 Submission from: chilli.mcc.wwwcache.ja.net (194.83.240.17) In the current CVS tree, the files _sre.c, sre.h, and sre_constants.h contain CR/LF windows-style line endings, which the MipsPro 7.2.1 compiler does not accept. From guido@python.org Mon Apr 10 18:34:11 2000 From: guido@python.org (guido@python.org) Date: Mon, 10 Apr 2000 13:34:11 -0400 (EDT) Subject: [Python-bugs-list] CR/LF line endings in _sre.c sre.h sre_constants.h (PR#284) Message-ID: <20000410173411.0F3C91CD4F@dinsdale.python.org> > In the current CVS tree, the files _sre.c, sre.h, and > sre_constants.h contain CR/LF windows-style line endings, which the > MipsPro 7.2.1 compiler does not accept. Try again. I just checked in new versions which fix this, about 5 minutes ago! --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@mojam.com Mon Apr 10 21:21:26 2000 From: skip@mojam.com (skip@mojam.com) Date: Mon, 10 Apr 2000 16:21:26 -0400 (EDT) Subject: [Python-bugs-list] wording confusion in API doc (PR#285) Message-ID: <20000410202126.232891CD7F@dinsdale.python.org> Full_Name: Skip Montanaro Version: 1.6a2 OS: n/a Submission from: beluga.mojam.com (199.249.165.173) In the Reference Count Details section of the API document, the second paragraph begins: Conversely, when calling a function passes it a reference to an object, there are two possibilities: the function \emph{steals} a reference to the object, or it does not. I think it's supposed to be Conversely, when a calling function passes it a reference ... Skip From alex@shop.com Mon Apr 10 21:40:57 2000 From: alex@shop.com (alex@shop.com) Date: Mon, 10 Apr 2000 16:40:57 -0400 (EDT) Subject: [Python-bugs-list] urlparse (PR#286) Message-ID: <20000410204057.D500D1CDA5@dinsdale.python.org> Full_Name: Alex Jacobson Version: >=1.5 OS: win32 linux Submission from: (NULL) (208.36.81.99) urlparse requires that the url contain a "/" so that urlparse("http://foo.com?q=a#blah") results in ("http","foo.com?q=a#blah",....) urlparse should not require slashes in urls that have fragments or query strings. From kessler@ccdc.cam.ac.uk Tue Apr 11 11:32:43 2000 From: kessler@ccdc.cam.ac.uk (kessler@ccdc.cam.ac.uk) Date: Tue, 11 Apr 2000 06:32:43 -0400 (EDT) Subject: [Python-bugs-list] CR/LF line endings in _sre.c sre.h sre_constants.h (PR#287) Message-ID: <20000411103243.411421CE0A@dinsdale.python.org> Full_Name: Magnus Kessler Version: 1.6a (10.04.2000) OS: Irix 6.3 Submission from: evander.mcc.wwwcache.ja.net (194.83.240.36) In the current CVS tree, the files _sre.c, sre.h, and sre_constants.h contain CR/LF windows-style line endings, which the MipsPro 7.2.1 compiler does not accept. From kessler@ccdc.cam.ac.uk Tue Apr 11 11:58:40 2000 From: kessler@ccdc.cam.ac.uk (kessler@ccdc.cam.ac.uk) Date: Tue, 11 Apr 2000 06:58:40 -0400 (EDT) Subject: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288) Message-ID: <20000411105840.948D11CE0B@dinsdale.python.org> Full_Name: Magnus Kessler Version: 1.6a2 OS: Irix6.3 Submission from: chilli.mcc.wwwcache.ja.net (194.83.240.17) Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal works fine (?) if you run it on its own: >>> import test.test_signal starting pause() loop... call pause()... + kill -5 7487 + sleep 2 handlerA (5, ) pause() returned call pause()... + kill -2 7487 + sleep 2 handlerB (2, ) HandlerBCalled exception caught call pause()... + kill -3 7487 KeyboardInterrupt (assume the alarm() went off) however, as part of the test suite, this test hangs: >>> import test.testall [...] test_signal test_signal + sleep 2 starting pause() loop... call pause()... + kill -5 7454 + sleep 2 + kill -2 7454 + sleep 2 + kill -3 7454 From guido@python.org Tue Apr 11 16:24:55 2000 From: guido@python.org (guido@python.org) Date: Tue, 11 Apr 2000 11:24:55 -0400 (EDT) Subject: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288) Message-ID: <20000411152455.24C591CDDA@dinsdale.python.org> > Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal > works fine (?) if you run it on its own: > > >>> import test.test_signal > starting pause() loop... > call pause()... > + kill -5 7487 > + sleep 2 > handlerA (5, ) > pause() returned > call pause()... > + kill -2 7487 > + sleep 2 > handlerB (2, ) > HandlerBCalled exception caught > call pause()... > + kill -3 7487 > KeyboardInterrupt (assume the alarm() went off) > > however, as part of the test suite, this test hangs: > > >>> import test.testall > [...] > test_signal > test_signal > + sleep 2 > starting pause() loop... > call pause()... > + kill -5 7454 > + sleep 2 > + kill -2 7454 > + sleep 2 > + kill -3 7454 Yes, I've seen this too. Unfortunately, I don't have a clue, and I don't have the time to delve into it... I bet there's a compile time #define that might do it. It may have something to do with threads... --Guido van Rossum (home page: http://www.python.org/~guido/) From bchen@exelixis.com Tue Apr 11 23:52:56 2000 From: bchen@exelixis.com (bchen@exelixis.com) Date: Tue, 11 Apr 2000 18:52:56 -0400 (EDT) Subject: [Python-bugs-list] DCOracle select max() always returns integers (PR#289) Message-ID: <20000411225256.9E0501CD5E@dinsdale.python.org> Full_Name: Bin Version: 1.5.2 OS: SUN Solaris Submission from: shaker.exelixis.com (209.0.11.254) I am using DCOracle to retrieve the max and min values of an attribute from a database. The attribute contains floating point numbers. If I use select attr_name from table_name I got a list of floating point numbers. But if I call select max(attr_name) from table_name I always got integers. Can anyone help me figure out what's wrong? Thanks, Bin From nmm1@cam.ac.uk Wed Apr 12 12:44:57 2000 From: nmm1@cam.ac.uk (nmm1@cam.ac.uk) Date: Wed, 12 Apr 2000 07:44:57 -0400 (EDT) Subject: [Python-bugs-list] Environment dependency in re parser (PR#290) Message-ID: <20000412114457.401F51CE44@dinsdale.python.org> Full_Name: Nick Maclaren Version: 1.5.2 OS: Irix 6.5 Submission from: posh.mcc.wwwcache.ja.net (194.83.240.29) The following code works perfectly when used interactively: from re import match if match(r'"([^\"]|\?""|\\?)*"','"abc"') : print "Hello" When run non-interactively (e.g. 'python junk.py'), it fails: File "junk.py", line 3, in ? if match(r'"([^\"]|\?""|\\?)*"','"abc"') : File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match return _cachecompile(pattern, flags).match(string) File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in _cachecompile value = compile(pattern, flags) File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('operand of unlimited repeat could match the empty string', 17) From nmm1@cus.cam.ac.uk Wed Apr 12 12:48:29 2000 From: nmm1@cus.cam.ac.uk (nmm1@cus.cam.ac.uk) Date: Wed, 12 Apr 2000 07:48:29 -0400 (EDT) Subject: [Python-bugs-list] Problems in Python 1.6 alpha 1 (PR#291) Message-ID: <20000412114829.DECB51CE44@dinsdale.python.org> I understood the comments in the release notes to say post these to the newsgroup, but I am not sure that is correct. Anyway, here is a slightly corrected report on the building process. Here are some problems with building and running the tests of the 1.6 Alpha release: 1) The Modules/sre* files have control-M at the end. 2) The 'unsigned char *' on lines 596 and 631 of mmapmodule.c should be 'char *'. There is also a pointless check '(where >= 0)' for an unsigned value on line 408. 3) _sre.c lines 222 and 225 and mmapmodule.c lines 715 compare pointers to object types and pointers to void - this is not allowed, but I don't think that it is particularly unsafe. But it is a hard error in a few compilers, so should be fixed. 4) If the call to mmap in mmapmodule.c fails, the diagnostic is "Invalid argument" - which can be downright wrong (as it was in this case.) 5) There is something very odd with the test harness, though I can't see the problem in regrtest.py. 'make test' says test_pyexpat crashed, but running the single test says that the module is not configured. This happens even under Irix. 6) test_unicode fails on Hitachi systems -- Writing: '*', expected: 'T'. Again, I failed to tie it down, and it looks like a test harness problem. 7) configure is still buggy and gets things wrong :-( 8) A few other failures weren't Python's fault, and I have reported them to the vendors. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679 From mal@lemburg.com Wed Apr 12 17:14:19 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 12 Apr 2000 18:14:19 +0200 Subject: [Python-bugs-list] Problems in Python 1.6 alpha 1 (PR#291) References: <20000412114829.DECB51CE44@dinsdale.python.org> Message-ID: <38F4A0DB.3884C0DB@lemburg.com> nmm1@cus.cam.ac.uk wrote: > > 5) There is something very odd with the test harness, though I can't > see the problem in regrtest.py. 'make test' says test_pyexpat crashed, > but running the single test says that the module is not configured. This > happens even under Irix. > > 6) test_unicode fails on Hitachi systems -- Writing: '*', expected: > 'T'. Again, I failed to tie it down, and it looks like a test harness > problem. > Could you send me the output of test_unicode.py so that I can check where the error happens ? Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Apr 12 17:11:59 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Wed, 12 Apr 2000 12:11:59 -0400 (EDT) Subject: [Python-bugs-list] Problems in Python 1.6 alpha 1 (PR#291) Message-ID: <20000412161159.4FD2D1CE76@dinsdale.python.org> nmm1@cus.cam.ac.uk wrote: > > 5) There is something very odd with the test harness, though I can't > see the problem in regrtest.py. 'make test' says test_pyexpat crashed, > but running the single test says that the module is not configured. This > happens even under Irix. > > 6) test_unicode fails on Hitachi systems -- Writing: '*', expected: > 'T'. Again, I failed to tie it down, and it looks like a test harness > problem. > Could you send me the output of test_unicode.py so that I can check where the error happens ? Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From kajiyama@grad.sccs.chukyo-u.ac.jp Wed Apr 12 20:03:34 2000 From: kajiyama@grad.sccs.chukyo-u.ac.jp (kajiyama@grad.sccs.chukyo-u.ac.jp) Date: Wed, 12 Apr 2000 15:03:34 -0400 (EDT) Subject: [Python-bugs-list] prefix directory (PR#292) Message-ID: <20000412190334.3F0E81CE94@dinsdale.python.org> Full_Name: Tamito KAJIYAMA Version: 1.6a2 OS: Plamo Linux 1.3 Submission from: dhcp236.grad.sccs.chukyo-u.ac.jp (150.42.18.236) The installation procedure ("make install") fails if the prefix directory specified with configure's --prefix option. From kajiyama@grad.sccs.chukyo-u.ac.jp Wed Apr 12 20:14:11 2000 From: kajiyama@grad.sccs.chukyo-u.ac.jp (kajiyama@grad.sccs.chukyo-u.ac.jp) Date: Wed, 12 Apr 2000 15:14:11 -0400 (EDT) Subject: [Python-bugs-list] prefix directory (PR#293) Message-ID: <20000412191411.6EA971CE98@dinsdale.python.org> Full_Name: Tamito KAJIYAMA Version: 1.6a2 OS: Plamo Linux 1.3 Submission from: dhcp236.grad.sccs.chukyo-u.ac.jp (150.42.18.236) (Repost: excuse me for annoyance) The installation procedure ("make install") fails if the prefix directory specified with configure's --prefix option does not exist. Manually making the prefix directory is sufficient, but automatic creation may be more preferable. From tim_one@email.msn.com Thu Apr 13 03:30:46 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 12 Apr 2000 22:30:46 -0400 Subject: [Python-bugs-list] Environment dependency in re parser (PR#290) In-Reply-To: <20000412114457.401F51CE44@dinsdale.python.org> Message-ID: <000001bfa4f0$47192600$09a0143f@tim> > Full_Name: Nick Maclaren > Version: 1.5.2 > OS: Irix 6.5 > Submission from: posh.mcc.wwwcache.ja.net (194.83.240.29) > > > The following code works perfectly when used interactively: > > from re import match > > if match(r'"([^\"]|\?""|\\?)*"','"abc"') : > print "Hello" > > When run non-interactively (e.g. 'python junk.py'), it fails: > > File "junk.py", line 3, in ? > if match(r'"([^\"]|\?""|\\?)*"','"abc"') : > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match > return _cachecompile(pattern, flags).match(string) > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in > _cachecompile > value = compile(pattern, flags) > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile > code=pcre_compile(pattern, flags, groupindex) > pcre.error: ('operand of unlimited repeat could match the empty > string', 17) It yields the same error for me whether run interactively or from file, under the released 1.5.2 for Windows, here run from a DOS box: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from re import match >>> if match(r'"([^\"]|\?""|\\?)*"','"abc"') : ... print "Hello" ... Traceback (innermost last): File "", line 1, in ? File "D:\Python\Lib\re.py", line 40, in match return _cachecompile(pattern, flags).match(string) File "D:\Python\Lib\re.py", line 33, in _cachecompile value = compile(pattern, flags) File "D:\Python\Lib\re.py", line 79, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('operand of unlimited repeat could match the empty string', 17) >>> The error msg is appropriate, since the third branch of the alternative matches 0 or 1 backslashes, so the alternative as a whole can match the empty string -- the error msg means exactly what it says. This is functioning correctly as designed. Perhaps you're using an interactive shell with a filter (readline?) that's chewing up some of the backslashes itself? From tim_one@email.msn.com Thu Apr 13 03:28:58 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Wed, 12 Apr 2000 22:28:58 -0400 (EDT) Subject: [Python-bugs-list] Environment dependency in re parser (PR#290) Message-ID: <20000413022858.B5D621CEBD@dinsdale.python.org> > Full_Name: Nick Maclaren > Version: 1.5.2 > OS: Irix 6.5 > Submission from: posh.mcc.wwwcache.ja.net (194.83.240.29) > > > The following code works perfectly when used interactively: > > from re import match > > if match(r'"([^\"]|\?""|\\?)*"','"abc"') : > print "Hello" > > When run non-interactively (e.g. 'python junk.py'), it fails: > > File "junk.py", line 3, in ? > if match(r'"([^\"]|\?""|\\?)*"','"abc"') : > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match > return _cachecompile(pattern, flags).match(string) > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in > _cachecompile > value = compile(pattern, flags) > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile > code=pcre_compile(pattern, flags, groupindex) > pcre.error: ('operand of unlimited repeat could match the empty > string', 17) It yields the same error for me whether run interactively or from file, under the released 1.5.2 for Windows, here run from a DOS box: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from re import match >>> if match(r'"([^\"]|\?""|\\?)*"','"abc"') : ... print "Hello" ... Traceback (innermost last): File "", line 1, in ? File "D:\Python\Lib\re.py", line 40, in match return _cachecompile(pattern, flags).match(string) File "D:\Python\Lib\re.py", line 33, in _cachecompile value = compile(pattern, flags) File "D:\Python\Lib\re.py", line 79, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('operand of unlimited repeat could match the empty string', 17) >>> The error msg is appropriate, since the third branch of the alternative matches 0 or 1 backslashes, so the alternative as a whole can match the empty string -- the error msg means exactly what it says. This is functioning correctly as designed. Perhaps you're using an interactive shell with a filter (readline?) that's chewing up some of the backslashes itself? From mak@mikroplan.com.pl Thu Apr 13 09:09:38 2000 From: mak@mikroplan.com.pl (mak@mikroplan.com.pl) Date: Thu, 13 Apr 2000 04:09:38 -0400 (EDT) Subject: [Python-bugs-list] ihooks on windows and pythoncom (PR#294) Message-ID: <20000413080938.1F8461CE74@dinsdale.python.org> Full_Name: Grzegorz Makarewicz Version: cvs OS: windows Submission from: mpip18.mikroplan.com.pl (195.117.158.18) Hi, Python module ihooks is not so compatible with builtin imp while importing modules whose name is stored in registry eg. pythoncom/pywintypes. import ihooks ihooks.install() import pythoncom This code will fail inside pythonwin ide too ! From niels@endea.demon.nl Thu Apr 13 19:16:27 2000 From: niels@endea.demon.nl (niels@endea.demon.nl) Date: Thu, 13 Apr 2000 14:16:27 -0400 (EDT) Subject: [Python-bugs-list] Invalid use of PyMem_DEL (PR#295) Message-ID: <20000413181627.EA4DD1CF15@dinsdale.python.org> Full_Name: Niels Diepeveen Version: 1.5.2 and 1.6.a2 OS: Win95 and Linux Submission from: endea.demon.nl (195.173.229.149) Hi, I ran into a bug while running a regrtest on 1.6a2 with debugging on. This produced a reference checking problem, which I now see is the same as reported in #113. I have tracked this down to the use of PyMem_DEL on an object created by PyObject_NEW in PyPcre_compile. When the compile fails, the new object is deallocated, but not removed from the reference chain. This also happens in 1.5.2. With a little grepping, I tracked down a few instances of this problem: pcremodule.c:PyPcre_compile unicodeobject.c:_PyUnicode_New socketmodule.c:newSSLObject threadmodule.c:newlockobject In each case a partially constructed, but already registered object is simply deleted without calling _Py_ForgetReference. From oli@andrich.net Thu Apr 13 20:18:09 2000 From: oli@andrich.net (oli@andrich.net) Date: Thu, 13 Apr 2000 15:18:09 -0400 (EDT) Subject: [Python-bugs-list] test_fork1 hangs with 1.6a2 on Linux (PR#296) Message-ID: <20000413191809.29FAD1CE1B@dinsdale.python.org> Full_Name: Oliver Andrich Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Submission from: gothic.andrich.net (212.7.175.226) Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver From oli@rz-online.net Thu Apr 13 21:23:44 2000 From: oli@rz-online.net (oli@rz-online.net) Date: Thu, 13 Apr 2000 16:23:44 -0400 (EDT) Subject: [Python-bugs-list] Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Message-ID: <20000413202344.0BA611CD27@dinsdale.python.org> Hi, well what I have discovered so far is. - Normal optimizations for Mandrake packages results in a sure segfault. - Normal python optimizations (jst calling make) causes hangs sometimes works. A look at ps ax shows, that there exist 6 active python "processes" (the parent process and 5 threads) and one defunct python process (the child). So thet child terminates correctly as I already mentioned. But the os.waitpid doesn't discover that the child has already exited. Things I will to tonight: - write a complete cversion of the testcode - compile python against another thread library - compile python against the most recent glibc snapshot - compile python on a RedHat 6.1 system Hopefully I get some more insights. Sadly, I am not good at c debugging, as I am a Python code by choice and a C coder who has written his last C code five years ago (a really program not just a Python extension ;-). Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred From oli@rz-online.net Thu Apr 13 22:35:41 2000 From: oli@rz-online.net (oli@rz-online.net) Date: Thu, 13 Apr 2000 17:35:41 -0400 (EDT) Subject: [Python-bugs-list] Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Message-ID: <20000413213541.4F5781CD0C@dinsdale.python.org> Hi, I just checked the following to things. I patched the threading to work with GNU pth and get the same results. When I run the test script with Python 1.5.2 on the same machine, that means same glibc and so on, it works fine. I compared the threading code of Python 1.5.2 and 1.6.a2 and it doesn't seem to differ at all. Same for the posixcode as far it is relevant for the test. I am a little bit irritated by this. Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred From ovi@physics.utoronto.ca Sat Apr 15 20:57:02 2000 From: ovi@physics.utoronto.ca (ovi@physics.utoronto.ca) Date: Sat, 15 Apr 2000 15:57:02 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: IDLE bug (PR#297) Message-ID: <20000415195702.63C661CD75@dinsdale.python.org> Full_Name: Ovidiu Toader Version: Python 1.6a2 (#15, Apr 7 2000, 21:14:35) OS: Linux alpha Submission from: phoenix.physics.utoronto.ca (128.100.78.35) This is an IDLE related problem: phoenix:Work> idle /usr/local/Packages/lang/python/install/../python/dist/src/Tools/idle/idle.py Traceback (most recent call last): File "/usr/local/bin/idle", line 17, in ? PyShell.main() ...... cut .... File "/usr/local/Packages/lang/python/install/lib/python1.6/ConfigParser.py", line 243, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: EditorWindow The problem is caused by the fact that idle.py assumes the configuration files to be located in the directory where the executable is found. I do not think that having a link from /usr/local/bin/idle to /path/to/idle.py is uncommon on unix. The following patch fixes this small problem. The patch is against the latest CVS sources. ------------------------------------------------------------------------------- I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Index: idle.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Tools/idle/idle.py,v retrieving revision 1.2 diff -c -r1.2 idle.py *** idle.py 2000/03/03 23:06:45 1.2 --- idle.py 2000/04/15 19:35:51 *************** *** 4,10 **** import sys import IdleConf ! idle_dir = os.path.split(sys.argv[0])[0] IdleConf.load(idle_dir) # defer importing Pyshell until IdleConf is loaded --- 4,14 ---- import sys import IdleConf ! exe_path = sys.argv[0] ! while os.path.islink(exe_path): ! exe_path = os.readlink(exe_path) ! ! idle_dir = os.path.split(exe_path)[0] IdleConf.load(idle_dir) # defer importing Pyshell until IdleConf is loaded From jeremy@cnri.reston.va.us Sun Apr 16 18:33:17 2000 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Sun, 16 Apr 2000 13:33:17 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: IDLE bug (PR#297) In-Reply-To: <20000415195702.63C661CD75@dinsdale.python.org> References: <20000415195702.63C661CD75@dinsdale.python.org> Message-ID: <14585.63837.768477.933135@bitdiddle.cnri.reston.va.us> Fred Drake fixed this problem in the IDLE sources last week. He uses a slightly different mechanism -- the __file__ attribute of a module loaded from the IDLE source directory. idle_dir = os.path.dirname(IdleConf.__file__) IdleConf.load(idle_dir) Jeremy From jeremy@cnri.reston.va.us Sun Apr 16 18:30:49 2000 From: jeremy@cnri.reston.va.us (jeremy@cnri.reston.va.us) Date: Sun, 16 Apr 2000 13:30:49 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: IDLE bug (PR#297) Message-ID: <20000416173049.6E6601CDDF@dinsdale.python.org> Fred Drake fixed this problem in the IDLE sources last week. He uses a slightly different mechanism -- the __file__ attribute of a module loaded from the IDLE source directory. idle_dir = os.path.dirname(IdleConf.__file__) IdleConf.load(idle_dir) Jeremy From fdrake@acm.org Mon Apr 17 15:05:58 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 17 Apr 2000 10:05:58 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: IDLE bug (PR#297) In-Reply-To: <20000415195702.63C661CD75@dinsdale.python.org> References: <20000415195702.63C661CD75@dinsdale.python.org> Message-ID: <14587.6726.494458.627593@seahag.cnri.reston.va.us> ovi@physics.utoronto.ca writes: > The problem is caused by the fact that idle.py assumes the configuration files > to be located in the directory where the executable is found. > I do not think that having a link from /usr/local/bin/idle to /path/to/idle.py > is uncommon on unix. The following patch fixes this small problem. The patch is > against the latest CVS sources. Are you sure you were using the latest sources from CVS? I fixed this (in a slightly simpler way) late last week. If what's currently in CVS doesn't work for you, be sure to let us know! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Mon Apr 17 15:02:17 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Mon, 17 Apr 2000 10:02:17 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: IDLE bug (PR#297) Message-ID: <20000417140217.CA5771CDFD@dinsdale.python.org> ovi@physics.utoronto.ca writes: > The problem is caused by the fact that idle.py assumes the configuration files > to be located in the directory where the executable is found. > I do not think that having a link from /usr/local/bin/idle to /path/to/idle.py > is uncommon on unix. The following patch fixes this small problem. The patch is > against the latest CVS sources. Are you sure you were using the latest sources from CVS? I fixed this (in a slightly simpler way) late last week. If what's currently in CVS doesn't work for you, be sure to let us know! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From magnus@thinkware.se Tue Apr 18 13:37:05 2000 From: magnus@thinkware.se (magnus@thinkware.se) Date: Tue, 18 Apr 2000 08:37:05 -0400 (EDT) Subject: [Python-bugs-list] IDLE class browser and decimal comma don't agree (PR#298) Message-ID: <20000418123705.2FC901CDB9@dinsdale.python.org> Full_Name: Magnus Lyckå Version: 1.5.2 OS: NT 4 Submission from: natrfv.sfa.se (194.71.67.10) As soon as I open the class browser in IDLE (0.5) I get the traceback below. Previously I had another strange bug that I suspect has to do with Tcl/Tk and the fact that I have national settings with , (comma) as decimal separator. With IDLE 0.4, >>> 5 / float(2) would result in 2,5 (not 2.5). It also wanted me to enter data like that. >>> 2.5 * 2 was rejected, and obviously >>> 2,5 * 2 was interpreted as (2, 5) * 2. This was only a problem in the IDLE shell. Program files ran OK. Considering "ValueError: invalid literal for float(): 0.0" below I suspect the errors are related. (A hint is that the problem goes away if I change the regional settings to decimal . in the control panel.) >>> Exception in Tkinter callback Traceback (innermost last): File "C:\Program\Python\Lib\lib-tk\Tkinter.py", line 764, in __call__ return apply(self.func, args) File "C:\Program\Python\Tools\idle\EditorWindow.py", line 355, in open_class_browser ClassBrowser.ClassBrowser(self.flist, base, [head]) File "C:\Program\Python\Tools\idle\ClassBrowser.py", line 37, in __init__ self.init(flist) File "C:\Program\Python\Tools\idle\ClassBrowser.py", line 59, in init node.expand() File "C:\Program\Python\Tools\idle\TreeWidget.py", line 133, in expand self.view() File "C:\Program\Python\Tools\idle\TreeWidget.py", line 144, in view visible_top = self.canvas.canvasy(0) File "C:\Program\Python\Lib\lib-tk\Tkinter.py", line 1200, in canvasy return getdouble(self.tk.call( ValueError: invalid literal for float(): 0.0 From greg@itasoftware.com Wed Apr 19 00:29:20 2000 From: greg@itasoftware.com (greg@itasoftware.com) Date: Tue, 18 Apr 2000 19:29:20 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) Message-ID: <20000418232920.760551CD7B@dinsdale.python.org> Hi, I was getting this error: Fatal Python error: PyThreadState_Delete: invalid tstate in a threaded program. Eventually I looked on your bug list pages and found the fix, and after several hours was able to get the code from CVS, update to r152, and then update Python/pystate.c to rev 2.9, for which the log message says: > revision 2.9 > date: 1999/06/18 14:22:24; author: guido; state: Exp; lines: +23 -5 > CRITICAL PATCH! > > We occasionally received reports from people getting "invalid tstate" > crashes (this is a fatal error in PyThreadState_Delete()). Finally > several people were able to reproduce it reliably and Tim Peters > discovered that there is a race condition when multiple threads are > calling this function without holding the global interpreter lock (the > function may be called without holding that). > > Solved the race condition by adding a lock around the mutating uses of > interp->tstate_head. Tim and Jonathan Giddy have run tests that make > it likely that this fixes the crashes -- although Tim hasn't heard > from the person who reported the original problem. My question is, what is some normal user supposed to do? Given that the bug was fixed in June of 1999 and you didn't have a next release planned for at least a year, wasn't a 1.5.3 warranted for a "CRITICAL PATCH"? thank you for your time, Greg Klanderman greg@itasoftware.com From guido@python.org Wed Apr 19 01:21:08 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 18 Apr 2000 20:21:08 -0400 Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) In-Reply-To: Your message of "Tue, 18 Apr 2000 19:29:20 EDT." <20000418232920.760551CD7B@dinsdale.python.org> References: <20000418232920.760551CD7B@dinsdale.python.org> Message-ID: <200004190021.UAA13857@eric.cnri.reston.va.us> > My question is, what is some normal user supposed to do? Given that > the bug was fixed in June of 1999 and you didn't have a next release > planned for at least a year, wasn't a 1.5.3 warranted for a "CRITICAL > PATCH"? The bug occurs VERY rarely. The problem with issueing a new release just to fix this is that lots of other, not so critical, changes would have to be vetted as well. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Apr 19 01:18:38 2000 From: guido@python.org (guido@python.org) Date: Tue, 18 Apr 2000 20:18:38 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) Message-ID: <20000419001838.4E9711CD8A@dinsdale.python.org> > My question is, what is some normal user supposed to do? Given that > the bug was fixed in June of 1999 and you didn't have a next release > planned for at least a year, wasn't a 1.5.3 warranted for a "CRITICAL > PATCH"? The bug occurs VERY rarely. The problem with issueing a new release just to fix this is that lots of other, not so critical, changes would have to be vetted as well. --Guido van Rossum (home page: http://www.python.org/~guido/) From greg@itasoftware.com Wed Apr 19 02:04:09 2000 From: greg@itasoftware.com (Greg Klanderman) Date: Tue, 18 Apr 2000 21:04:09 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) In-Reply-To: <200004190021.UAA13857@eric.cnri.reston.va.us> References: <20000418232920.760551CD7B@dinsdale.python.org> <200004190021.UAA13857@eric.cnri.reston.va.us> Message-ID: <14589.1545.542476.576374@phl.itasoftware.com> >>>>> Guido van Rossum writes: >> My question is, what is some normal user supposed to do? Given that >> the bug was fixed in June of 1999 and you didn't have a next release >> planned for at least a year, wasn't a 1.5.3 warranted for a "CRITICAL >> PATCH"? > The bug occurs VERY rarely. The problem with issueing a new release > just to fix this is that lots of other, not so critical, changes would > have to be vetted as well. Hi Guido, Thanks for the reply. You seem to be saying that since other changes had been made to the codebase between when 1.5.2 was released and when this bug was fixed that releasing a fixed 1.5.2 would have required incorporating all those other changes. If so, that is not at all true. You should create a branch in your CVS repository at 1.5.2, fix the bug in that branch (and any others that are found in the 1.5.x lineage, at least until the next stable release), and continue developing 1.6 as normal. The only downside is that you have to check bugfixes to 1.5.x series into both that branch and the main development branch (1.6) - which is really not that bad at all. A release methodology like this is really the only way to get an absolutely, 100% rock solid version of python out there, as you cannot expect to catch every last bug in a short alpha/beta testing cycle. Greg From greg@itasoftware.com Wed Apr 19 02:01:35 2000 From: greg@itasoftware.com (greg@itasoftware.com) Date: Tue, 18 Apr 2000 21:01:35 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) Message-ID: <20000419010135.868071CDA0@dinsdale.python.org> >>>>> Guido van Rossum writes: >> My question is, what is some normal user supposed to do? Given that >> the bug was fixed in June of 1999 and you didn't have a next release >> planned for at least a year, wasn't a 1.5.3 warranted for a "CRITICAL >> PATCH"? > The bug occurs VERY rarely. The problem with issueing a new release > just to fix this is that lots of other, not so critical, changes would > have to be vetted as well. Hi Guido, Thanks for the reply. You seem to be saying that since other changes had been made to the codebase between when 1.5.2 was released and when this bug was fixed that releasing a fixed 1.5.2 would have required incorporating all those other changes. If so, that is not at all true. You should create a branch in your CVS repository at 1.5.2, fix the bug in that branch (and any others that are found in the 1.5.x lineage, at least until the next stable release), and continue developing 1.6 as normal. The only downside is that you have to check bugfixes to 1.5.x series into both that branch and the main development branch (1.6) - which is really not that bad at all. A release methodology like this is really the only way to get an absolutely, 100% rock solid version of python out there, as you cannot expect to catch every last bug in a short alpha/beta testing cycle. Greg From tim_one@email.msn.com Wed Apr 19 03:18:23 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 18 Apr 2000 22:18:23 -0400 Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) In-Reply-To: <20000418232920.760551CD7B@dinsdale.python.org> Message-ID: <001601bfa9a5$89e13900$bda0143f@tim> [greg@itasoftware.com] > I was getting this error: > > Fatal Python error: PyThreadState_Delete: invalid tstate > > in a threaded program. > > Eventually I looked on your bug list pages and found the fix, > > ... > > My question is, what is some normal user supposed to do? Well, (a) a "normal user" usually doesn't use threads at all, and (b) this bug was exceedingly rare even among abnormal users; e.g., it took me extreme efforts to provoke the bug at all on a uniprocessor machine, and I had never bumped into it before making that effort. I filed the bug report in the bug database after it was fixed, so that people could find it without stumbling into the Thread-SIG archives (BTW, if you're one of Python's serious thread users, you should sign up for that list!). Right after the fix, Guido posted a call for volunteers to put out a critical bugfix release, but nobody responded. A release (even a bugfix release) is a major effort, and nobody (including me) stepped up to the plate. So, you see, it's entirely your fault . > Given that the bug was fixed in June of 1999 and you didn't have a > next release planned for at least a year, What makes you think that the next release wasn't planned for at least a year? That's not my recollection. It will have *taken* a year by the time 1.6 gets out, but that's hindsight. > wasn't a 1.5.3 warranted for a "CRITICAL PATCH"? Yes, I think so, and Guido did too. Unfortunately, nobody made time to do the work. That's all there is to it. Sorry for the hassle! Alas, until someone gets paid to do Python work, you get what volunteers are able to do in their spare time. The good news is that the tstate bug is the most serious lapse I can recall in nearly a decade. From tim_one@email.msn.com Wed Apr 19 03:16:29 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 18 Apr 2000 22:16:29 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) Message-ID: <20000419021629.86DC31CDAF@dinsdale.python.org> [greg@itasoftware.com] > I was getting this error: > > Fatal Python error: PyThreadState_Delete: invalid tstate > > in a threaded program. > > Eventually I looked on your bug list pages and found the fix, > > ... > > My question is, what is some normal user supposed to do? Well, (a) a "normal user" usually doesn't use threads at all, and (b) this bug was exceedingly rare even among abnormal users; e.g., it took me extreme efforts to provoke the bug at all on a uniprocessor machine, and I had never bumped into it before making that effort. I filed the bug report in the bug database after it was fixed, so that people could find it without stumbling into the Thread-SIG archives (BTW, if you're one of Python's serious thread users, you should sign up for that list!). Right after the fix, Guido posted a call for volunteers to put out a critical bugfix release, but nobody responded. A release (even a bugfix release) is a major effort, and nobody (including me) stepped up to the plate. So, you see, it's entirely your fault . > Given that the bug was fixed in June of 1999 and you didn't have a > next release planned for at least a year, What makes you think that the next release wasn't planned for at least a year? That's not my recollection. It will have *taken* a year by the time 1.6 gets out, but that's hindsight. > wasn't a 1.5.3 warranted for a "CRITICAL PATCH"? Yes, I think so, and Guido did too. Unfortunately, nobody made time to do the work. That's all there is to it. Sorry for the hassle! Alas, until someone gets paid to do Python work, you get what volunteers are able to do in their spare time. The good news is that the tstate bug is the most serious lapse I can recall in nearly a decade. From bwarsaw@cnri.reston.va.us Wed Apr 19 16:47:03 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 19 Apr 2000 11:47:03 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) References: <20000418232920.760551CD7B@dinsdale.python.org> <200004190021.UAA13857@eric.cnri.reston.va.us> <14589.1545.542476.576374@phl.itasoftware.com> Message-ID: <14589.54519.54452.819828@anthem.cnri.reston.va.us> >>>>> "GK" == Greg Klanderman writes: GK> You should create a branch in your CVS repository at 1.5.2, GK> fix the bug in that branch (and any others that are found in GK> the 1.5.x lineage, at least until the next stable release), GK> and continue developing GK> 1.6 as normal. The only downside is that you have to check GK> bugfixes to 1.5.x series into both that branch and the main GK> development branch (1.6) - which is really not that bad at GK> all. The other downside is that CVS branches really don't work. We tried it with the string-methods stuff and it was a fiasco. We're trying to avoid branches if at all possible. -Barry From bwarsaw@cnri.reston.va.us Wed Apr 19 16:44:28 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 19 Apr 2000 11:44:28 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) Message-ID: <20000419154428.45A4C1CDFD@dinsdale.python.org> >>>>> "GK" == Greg Klanderman writes: GK> You should create a branch in your CVS repository at 1.5.2, GK> fix the bug in that branch (and any others that are found in GK> the 1.5.x lineage, at least until the next stable release), GK> and continue developing GK> 1.6 as normal. The only downside is that you have to check GK> bugfixes to 1.5.x series into both that branch and the main GK> development branch (1.6) - which is really not that bad at GK> all. The other downside is that CVS branches really don't work. We tried it with the string-methods stuff and it was a fiasco. We're trying to avoid branches if at all possible. -Barry From fdrake@acm.org Wed Apr 19 16:54:47 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 19 Apr 2000 11:54:47 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) In-Reply-To: <14589.54519.54452.819828@anthem.cnri.reston.va.us> References: <20000418232920.760551CD7B@dinsdale.python.org> <200004190021.UAA13857@eric.cnri.reston.va.us> <14589.1545.542476.576374@phl.itasoftware.com> <14589.54519.54452.819828@anthem.cnri.reston.va.us> Message-ID: <14589.54983.366024.714570@seahag.cnri.reston.va.us> Barry A. Warsaw writes: > The other downside is that CVS branches really don't work. We tried > it with the string-methods stuff and it was a fiasco. We're trying to > avoid branches if at all possible. Barry, After the merge of the documentation, I'm not sure I agree. The problem is with multiple merges, which seems to make more sense for parallel development branches, and not for single-merge situations (as for the documentation) or one branch being just critical bug fixes (as Greg is suggesting). In the bug-fix-only branch, you're typically migrating a specific patch into the tree from the development tree: just make the change and check it in. This may be a very reasonable approach even with the limited support for branches in CVS. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Wed Apr 19 16:51:03 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Wed, 19 Apr 2000 11:51:03 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) Message-ID: <20000419155103.7AF431CE10@dinsdale.python.org> Barry A. Warsaw writes: > The other downside is that CVS branches really don't work. We tried > it with the string-methods stuff and it was a fiasco. We're trying to > avoid branches if at all possible. Barry, After the merge of the documentation, I'm not sure I agree. The problem is with multiple merges, which seems to make more sense for parallel development branches, and not for single-merge situations (as for the documentation) or one branch being just critical bug fixes (as Greg is suggesting). In the bug-fix-only branch, you're typically migrating a specific patch into the tree from the development tree: just make the change and check it in. This may be a very reasonable approach even with the limited support for branches in CVS. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From greg@itasoftware.com Wed Apr 19 17:14:08 2000 From: greg@itasoftware.com (Greg Klanderman) Date: Wed, 19 Apr 2000 12:14:08 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) In-Reply-To: <14589.54983.366024.714570@seahag.cnri.reston.va.us> References: <20000418232920.760551CD7B@dinsdale.python.org> <200004190021.UAA13857@eric.cnri.reston.va.us> <14589.1545.542476.576374@phl.itasoftware.com> <14589.54519.54452.819828@anthem.cnri.reston.va.us> <14589.54983.366024.714570@seahag.cnri.reston.va.us> Message-ID: <14589.56144.731666.256430@phl.itasoftware.com> >>>>> Fred L Drake, writes: > Barry A. Warsaw writes: >> The other downside is that CVS branches really don't work. We tried >> it with the string-methods stuff and it was a fiasco. We're trying to >> avoid branches if at all possible. > Barry, > After the merge of the documentation, I'm not sure I agree. The > problem is with multiple merges, which seems to make more sense for > parallel development branches, and not for single-merge situations (as > for the documentation) or one branch being just critical bug fixes (as > Greg is suggesting). In the bug-fix-only branch, you're typically > migrating a specific patch into the tree from the development tree: > just make the change and check it in. This may be a very reasonable > approach even with the limited support for branches in CVS. Yes, while branches can cause big headaches in general, the problems are really caused by trying to join branches. But with a bugfix-only branch you never need to join, so they work just fine. Greg From greg@itasoftware.com Wed Apr 19 17:11:37 2000 From: greg@itasoftware.com (greg@itasoftware.com) Date: Wed, 19 Apr 2000 12:11:37 -0400 (EDT) Subject: [Python-bugs-list] Fatal Python error: PyThreadState_Delete: invalid tstate (PR#299) Message-ID: <20000419161137.34B6C1CE93@dinsdale.python.org> >>>>> Fred L Drake, writes: > Barry A. Warsaw writes: >> The other downside is that CVS branches really don't work. We tried >> it with the string-methods stuff and it was a fiasco. We're trying to >> avoid branches if at all possible. > Barry, > After the merge of the documentation, I'm not sure I agree. The > problem is with multiple merges, which seems to make more sense for > parallel development branches, and not for single-merge situations (as > for the documentation) or one branch being just critical bug fixes (as > Greg is suggesting). In the bug-fix-only branch, you're typically > migrating a specific patch into the tree from the development tree: > just make the change and check it in. This may be a very reasonable > approach even with the limited support for branches in CVS. Yes, while branches can cause big headaches in general, the problems are really caused by trying to join branches. But with a bugfix-only branch you never need to join, so they work just fine. Greg From mappel@attglobal.net Wed Apr 19 19:48:14 2000 From: mappel@attglobal.net (mappel@attglobal.net) Date: Wed, 19 Apr 2000 14:48:14 -0400 (EDT) Subject: [Python-bugs-list] Debugger crashes on Win2000 Professional (PR#300) Message-ID: <20000419184814.1C0EB1CE34@dinsdale.python.org> Full_Name: Michael Appelmans Version: 1.6a2, win32all 131 OS: Windows 2000 Pro Submission from: slip-32-100-40-151.oh.us.prserv.net (32.100.40.151) As soon as I start the debugger in Pythonwin a small window pops up, disappears and the exception listed below is raised. --------------------------------------------------------- Test program used to create the exception: def main(): line = "ssss"; print line; main(); --------------------------------------------------------- File "H:\Python16\lib\pdb.py", line 133, in interaction self.cmdloop() File "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 527, in cmdloop self.GUIAboutToBreak() File "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 782, in GUIAboutToBreak self.GUIAboutToInteract() File "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 813, in GUIAboutToInteract self.GUIRespondDebuggerData() File "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 768, in GUIRespondDebuggerData cb.RespondDebuggerData() File "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 207, in RespondDebuggerData if self.list.GetItemImage(handle)!= (col, selCol): File "H:\Python16\Pythonwin\pywin\mfc\object.py", line 22, in __getattr__ raise win32ui.error, "The MFC object has died." win32ui: The MFC object has died. From mhammond@skippinet.com.au Thu Apr 20 03:29:23 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 20 Apr 2000 12:29:23 +1000 Subject: [Python-bugs-list] Debugger crashes on Win2000 Professional (PR#300) In-Reply-To: <20000419184814.1C0EB1CE34@dinsdale.python.org> Message-ID: This is a known bug in win32all-131 - as soon as starship is back up I will have a patch available - or more likely a 132, as there are also some Unicode related bugs in Scintilla (eg, try entering a multi-line Python command in the interactive window [dont bother reporting that one :-]) Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > mappel@attglobal.net > Sent: Thursday, 20 April 2000 4:48 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Debugger crashes on Win2000 > Professional > (PR#300) > > > Full_Name: Michael Appelmans > Version: 1.6a2, win32all 131 > OS: Windows 2000 Pro > Submission from: slip-32-100-40-151.oh.us.prserv.net > (32.100.40.151) > > > As soon as I start the debugger in Pythonwin a small > window pops up, disappears > and the exception listed below is raised. > > --------------------------------------------------------- > Test program used to create the exception: > def main(): > line = "ssss"; > print line; > > main(); > --------------------------------------------------------- > File "H:\Python16\lib\pdb.py", line 133, in interaction > self.cmdloop() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line > 527, in cmdloop > self.GUIAboutToBreak() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 782, in > GUIAboutToBreak > self.GUIAboutToInteract() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 813, in > GUIAboutToInteract > self.GUIRespondDebuggerData() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 768, in > GUIRespondDebuggerData > cb.RespondDebuggerData() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 207, in > RespondDebuggerData > if self.list.GetItemImage(handle)!= (col, selCol): > File "H:\Python16\Pythonwin\pywin\mfc\object.py", line > 22, in __getattr__ > raise win32ui.error, "The MFC object has died." > win32ui: The MFC object has died. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mhammond@skippinet.com.au Thu Apr 20 03:27:12 2000 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Wed, 19 Apr 2000 22:27:12 -0400 (EDT) Subject: [Python-bugs-list] Debugger crashes on Win2000 Professional (PR#300) Message-ID: <20000420022712.6402A1CE9D@dinsdale.python.org> This is a known bug in win32all-131 - as soon as starship is back up I will have a patch available - or more likely a 132, as there are also some Unicode related bugs in Scintilla (eg, try entering a multi-line Python command in the interactive window [dont bother reporting that one :-]) Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > mappel@attglobal.net > Sent: Thursday, 20 April 2000 4:48 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Debugger crashes on Win2000 > Professional > (PR#300) > > > Full_Name: Michael Appelmans > Version: 1.6a2, win32all 131 > OS: Windows 2000 Pro > Submission from: slip-32-100-40-151.oh.us.prserv.net > (32.100.40.151) > > > As soon as I start the debugger in Pythonwin a small > window pops up, disappears > and the exception listed below is raised. > > --------------------------------------------------------- > Test program used to create the exception: > def main(): > line = "ssss"; > print line; > > main(); > --------------------------------------------------------- > File "H:\Python16\lib\pdb.py", line 133, in interaction > self.cmdloop() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line > 527, in cmdloop > self.GUIAboutToBreak() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 782, in > GUIAboutToBreak > self.GUIAboutToInteract() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 813, in > GUIAboutToInteract > self.GUIRespondDebuggerData() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 768, in > GUIRespondDebuggerData > cb.RespondDebuggerData() > File > "H:\Python16\Pythonwin\pywin\debugger\debugger.py", line 207, in > RespondDebuggerData > if self.list.GetItemImage(handle)!= (col, selCol): > File "H:\Python16\Pythonwin\pywin\mfc\object.py", line > 22, in __getattr__ > raise win32ui.error, "The MFC object has died." > win32ui: The MFC object has died. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From jon@dstc.edu.au Fri Apr 21 12:58:31 2000 From: jon@dstc.edu.au (jon@dstc.edu.au) Date: Fri, 21 Apr 2000 07:58:31 -0400 (EDT) Subject: [Python-bugs-list] Freeze still imports cmp (PR#301) Message-ID: <20000421115831.5969D1CD5F@dinsdale.python.org> Full_Name: Jonathan Giddy Version: 1.6a2 OS: Submission from: pig.cc.monash.edu.au (130.194.11.179) The freeze code still imports the obsolete cmp module (in bkfile.py) From brian_takashi@hotmail.com Fri Apr 21 20:14:43 2000 From: brian_takashi@hotmail.com (brian_takashi@hotmail.com) Date: Fri, 21 Apr 2000 15:14:43 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: temporary glitch in CVS codecs.c (PR#302) Message-ID: <20000421191443.BCED51CD42@dinsdale.python.org> Full_Name: Brian Hooper Version: CVS 2000/04/21 OS: Linux Submission from: ip89.san-francisco31.ca.pub-ip.psi.net (38.28.81.89) In the CVS tree as of this morning, the following snippet accidentally got checked in to CVS. I'm sure someone will notice this anyway soon - just wanted to send a heads up. --Brian Hooper if (func == NULL) goto onError; <<<<<<< codecs.c result = PyEval_CallObject(func, args); ======= result = PyEval_CallObject(func, args); >>>>>>> 2.3 if (result == NULL) From guido@python.org Fri Apr 21 20:17:46 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 21 Apr 2000 15:17:46 -0400 Subject: [Python-bugs-list] PRIVATE: temporary glitch in CVS codecs.c (PR#302) In-Reply-To: Your message of "Fri, 21 Apr 2000 15:14:43 EDT." <20000421191443.BCED51CD42@dinsdale.python.org> References: <20000421191443.BCED51CD42@dinsdale.python.org> Message-ID: <200004211917.PAA16760@eric.cnri.reston.va.us> > In the CVS tree as of this morning, the following snippet accidentally got > checked in to CVS. > > I'm sure someone will notice this anyway soon - just wanted to send a heads up. > > --Brian Hooper > > if (func == NULL) > goto onError; > <<<<<<< codecs.c > result = PyEval_CallObject(func, args); > ======= > result = PyEval_CallObject(func, args); > >>>>>>> 2.3 > if (result == NULL) Are you sure? I don't see this in in our CVS repository. What does "cvs update codecs.c" tell you? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Apr 21 20:17:58 2000 From: guido@python.org (guido@python.org) Date: Fri, 21 Apr 2000 15:17:58 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: temporary glitch in CVS codecs.c (PR#302) Message-ID: <20000421191758.B23891CD42@dinsdale.python.org> > In the CVS tree as of this morning, the following snippet accidentally got > checked in to CVS. > > I'm sure someone will notice this anyway soon - just wanted to send a heads up. > > --Brian Hooper > > if (func == NULL) > goto onError; > <<<<<<< codecs.c > result = PyEval_CallObject(func, args); > ======= > result = PyEval_CallObject(func, args); > >>>>>>> 2.3 > if (result == NULL) Are you sure? I don't see this in in our CVS repository. What does "cvs update codecs.c" tell you? --Guido van Rossum (home page: http://www.python.org/~guido/) From brian@garage.co.jp Fri Apr 21 21:19:59 2000 From: brian@garage.co.jp (Brian Hooper) Date: Fri, 21 Apr 2000 20:19:59 GMT Subject: [Python-bugs-list] PRIVATE: temporary glitch in CVS codecs.c (PR#302) Message-ID: <20000421201959.61019.qmail@hotmail.com> Oh, I figured out why this happened - I had the patch that Marc-Andre sent earlier applied to my working directory, so when I updated today the upstream change attempted to merge with my working copy, which already had the same change applied. Sorry for my confusion. --Brian Hooper >From: Guido van Rossum >To: brian_takashi@hotmail.com >CC: python-bugs-list@python.org, bugs-py@python.org >Subject: Re: [Python-bugs-list] PRIVATE: temporary glitch in CVS codecs.c >(PR#302) >Date: Fri, 21 Apr 2000 15:17:46 -0400 > > > In the CVS tree as of this morning, the following snippet accidentally >got > > checked in to CVS. > > > > I'm sure someone will notice this anyway soon - just wanted to send a >heads up. > > > > --Brian Hooper > > > > if (func == NULL) > > goto onError; > > <<<<<<< codecs.c > > result = PyEval_CallObject(func, args); > > ======= > > result = PyEval_CallObject(func, args); > > >>>>>>> 2.3 > > if (result == NULL) > >Are you sure? I don't see this in in our CVS repository. What does >"cvs update codecs.c" tell you? > >--Guido van Rossum (home page: http://www.python.org/~guido/) ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From brian@garage.co.jp Fri Apr 21 21:19:58 2000 From: brian@garage.co.jp (brian@garage.co.jp) Date: Fri, 21 Apr 2000 16:19:58 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: temporary glitch in CVS codecs.c (PR#302) Message-ID: <20000421201958.26FDC1CD3C@dinsdale.python.org> Oh, I figured out why this happened - I had the patch that Marc-Andre sent earlier applied to my working directory, so when I updated today the upstream change attempted to merge with my working copy, which already had the same change applied. Sorry for my confusion. --Brian Hooper >From: Guido van Rossum >To: brian_takashi@hotmail.com >CC: python-bugs-list@python.org, bugs-py@python.org >Subject: Re: [Python-bugs-list] PRIVATE: temporary glitch in CVS codecs.c >(PR#302) >Date: Fri, 21 Apr 2000 15:17:46 -0400 > > > In the CVS tree as of this morning, the following snippet accidentally >got > > checked in to CVS. > > > > I'm sure someone will notice this anyway soon - just wanted to send a >heads up. > > > > --Brian Hooper > > > > if (func == NULL) > > goto onError; > > <<<<<<< codecs.c > > result = PyEval_CallObject(func, args); > > ======= > > result = PyEval_CallObject(func, args); > > >>>>>>> 2.3 > > if (result == NULL) > >Are you sure? I don't see this in in our CVS repository. What does >"cvs update codecs.c" tell you? > >--Guido van Rossum (home page: http://www.python.org/~guido/) ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From caolan@skynet.ie Sat Apr 22 21:35:54 2000 From: caolan@skynet.ie (caolan@skynet.ie) Date: Sat, 22 Apr 2000 16:35:54 -0400 (EDT) Subject: [Python-bugs-list] poplib: failure to strip leading '.' (PR#303) Message-ID: <20000422203554.903971CD82@dinsdale.python.org> Full_Name: Caolan McNamara Version: 1.5.2 OS: all Submission from: calzone.stardiv.de (62.156.160.60) poplib: The pop rfc (rfc1725) states that if a multiline response leads with a '.' that the server will add another leading '.' to distinguish it from the end of message marker which is a line consisting of a single '.' poplib fails to strip this extra leading '.', this strikes me as a sneaky buglet. C. From chrism@digicool.com Sun Apr 23 06:51:24 2000 From: chrism@digicool.com (chrism@digicool.com) Date: Sun, 23 Apr 2000 01:51:24 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Tempfile module security issue (w/patch) (PR#304) Message-ID: <20000423055124.835391CDB8@dinsdale.python.org> Full_Name: Chris McDonough Version: CVS OS: All Submission from: 208-58-241-97.s605.tnt1.atnnj.pa.dialup.rcn.com (208.58.241.97) Folks, Hi. I've included a patch that I believe improves the security of the tempfile module. I'm using the web submission form instead of patches@python.org because I'm not sure if the list that patches gets sent to isn't public, and this is a security-related fix. Currently, on a posix platform, the module chooses a temp directory by finding the first of a few potential temp directories by trying to write to a file inside the temp directory that is named "@[PID].test" (e.g. "@8907.test"). It opens this file, writes out the string "blat" to it, and unlinks it. If it's successful, it uses that temp directory for further writing of tempfiles. Unfortunately, the test file isn't opened in a safe mode and follows symlinks. A symlink contained in Python's chosen temp directory, named properly, can cause Python to overwrite any process-writable file with the "blat" string. I've modified the module to test for a writable directory in much the same way the actual tempfile is created (using O_CREAT and O_EXCL) when the test is invoked on a posix platform. If the test is not invoked on a posix platform, the old method of testing is used. The included patch is against the CVS tempfile module: *** tempfile.py Sun Apr 23 00:55:34 2000 --- newtempfile.py Sun Apr 23 01:02:22 2000 *************** *** 42,54 **** testfile = gettempprefix() + 'test' for dir in attempdirs: try: ! filename = os.path.join(dir, testfile) ! fp = open(filename, 'w') ! fp.write('blat') ! fp.close() ! os.unlink(filename) ! tempdir = dir ! break except IOError: pass if tempdir is None: --- 42,69 ---- testfile = gettempprefix() + 'test' for dir in attempdirs: try: ! filename = os.path.join(dir, testfile) ! if os.name == 'posix': ! try: ! fd = os.open(filename, os.O_RDWR|os.O_CREAT|os.O_EXCL, ! 0700) ! except OSError: ! pass ! else: ! fp = os.fdopen(fd, 'w') ! fp.write('blat') ! fp.close() ! os.unlink(filename) ! del fp, fd ! tempdir = dir ! break ! else: ! fp = open(filename, 'w') ! fp.write('blat') ! fp.close() ! os.unlink(filename) ! tempdir = dir ! break except IOError: pass if tempdir is None: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Thanks! Chris McDonough Digital Creations Publishers of Zope - http://www.zope.org From cgw@alum.mit.edu Mon Apr 24 02:10:04 2000 From: cgw@alum.mit.edu (cgw@alum.mit.edu) Date: Sun, 23 Apr 2000 21:10:04 -0400 (EDT) Subject: [Python-bugs-list] unexpected UnicodeError (PR#305) Message-ID: <20000424011004.6734C1CDCD@dinsdale.python.org> Full_Name: charles g waldman Version: 1.6 CVS as of 4/23/00 OS: linux Submission from: 1cust180.tnt38.chi5.da.uu.net (63.26.93.180) Python 1.6a2 (#98, Apr 17 2000, 16:20:00) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> l=[u''] >>> c=chr(203) >>> c in l Traceback (most recent call last): File "", line 1, in ? UnicodeError: UTF-8 decoding error: unexpected end of data >>> From guido@python.org Mon Apr 24 14:28:32 2000 From: guido@python.org (guido@python.org) Date: Mon, 24 Apr 2000 09:28:32 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Tempfile module security issue (w/patch) (PR#304) Message-ID: <20000424132832.753631CDF8@dinsdale.python.org> Thanks, Chris! I've checked in a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From mark.favas@per.dem.csiro.au Tue Apr 25 00:26:27 2000 From: mark.favas@per.dem.csiro.au (mark.favas@per.dem.csiro.au) Date: Mon, 24 Apr 2000 19:26:27 -0400 (EDT) Subject: [Python-bugs-list] 1.6a2 issues with int/long on 64bit platforms - eg stringobject (PR#306) Message-ID: <20000424232627.C4DCC1CD9D@dinsdale.python.org> Full_Name: Mark Favas Version: 1.6a2 CVS of 25 April OS: DEC Alpha, Tru64 Unix 4.0F Submission from: wa107.dialup.csiro.au (130.116.4.107) There seems to be issues (and perhaps lurking cans of worms) on 64-bit platforms where sizeof(long) != sizeof(int). For example, the CVS version of 1.6a2 of 25 April fails the UserString regression test. The tests fail as follows (verbose set to 1): abcabcabc.count(('abc',)) no 'abcabcabc' 3 <> 2 abcabcabc.count(('abc', 1)) no 'abcabcabc' 2 <> 1 abcdefghiabc.find(('abc', 1)) no 'abcdefghiabc' 9 <> -1 abcdefghiabc.rfind(('abc',)) no 'abcdefghiabc' 9 <> 0 abcabcabc.rindex(('abc',)) no 'abcabcabc' 6 <> 3 abcabcabc.rindex(('abc', 1)) no 'abcabcabc' 6 <> 3 These tests are failing because the calls from the UserString methods to the underlying string methods are setting the default value of the end-of-string parameter to sys.maxint, which is defined as LONG_MAX (9223372036854775807), whereas the string methods in stringobject.c are using ints and expecting them to be no larger than INT_MAX (2147483647). Thus the end-of-string parameter becomes -1 in the default case. The size of an int on my platform is 4, and the size of a long is 8, so the "natural size of a Python integer" should be 8, by my understanding. The obvious fix is to change stringobject.c to use longs, rather than ints, but the problem might be more widespread than that. INT_MAX is used in unicodeobject.c, pypcre.c, _sre.c, stropmodule.c, and ceval.c as well as stringobject.c. Some of these look as though LONG_MAX should have been used (variables compared to INT_MAX are longs, but I am not confident enough to submit patches for them... Mark From gpk@bell-labs.com Fri Apr 28 16:28:21 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Fri, 28 Apr 2000 11:28:21 -0400 (EDT) Subject: [Python-bugs-list] time.sleep() and threading (PR#307) Message-ID: <20000428152821.2AB261CD9D@dinsdale.python.org> Full_Name: Greg Kochanski Version: 1.5.2 OS: Solaris 2.6 sparc Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) python .../test/test_thread.py shows that time.sleep() does not relinquish the processor. As one thread goes to sleep, another thread ought to start processing. That doesn't happen. Python was configured with --with-thread and compiler flags -mt and -D_REENTRANT. See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g EXAMPLE: hce* python test_thread.py creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 9.9 sec # goes to sleep here... task 1 done # 9.9 seconds later... task 5 will run for 4.1 sec # This should have started when task 1 slept. task 5 done task 7 will run for 9.9 sec task 7 done task 4 will run for 9.2 sec task 4 done task task 6 will run for 7.7 sec From jnc@ecs.soton.ac.uk Fri Apr 28 18:41:57 2000 From: jnc@ecs.soton.ac.uk (jnc@ecs.soton.ac.uk) Date: Fri, 28 Apr 2000 13:41:57 -0400 (EDT) Subject: [Python-bugs-list] idle dosnt recompile modules changed externally (PR#308) Message-ID: <20000428174157.C8B3A1CD60@dinsdale.python.org> Full_Name: John Carter Version: 1.5.2 OS: windows 98 Submission from: host62-7-13-197.btinternet.com (62.7.13.197) Consider two scripts showbug.py ===== import bug1 bug1.bug() ===== and bug1.py ===== def bug(): print 'Bug 5' ===== both in the same directory. load showbug.py into idle (0.5) and runit with F5, the bug function prints Bug 5 Now change bug1.py outside or even with idle, save it. dates on disk now show bug1.py is newer than bug1.pyc rerun showbug.py pressing F5 or ctrl-F5 it still prints Bug 5. I dont think this behaviour is what is required.Certainly it cost me most of the afternoon tracking down non-existant problems in my code. John Carter From guido@python.org Fri Apr 28 19:45:37 2000 From: guido@python.org (guido@python.org) Date: Fri, 28 Apr 2000 14:45:37 -0400 (EDT) Subject: [Python-bugs-list] idle dosnt recompile modules changed externally (PR#308) Message-ID: <20000428184537.8994B1CD1F@dinsdale.python.org> > Consider two scripts > > showbug.py > ===== > > import bug1 > > bug1.bug() > ===== > and bug1.py > ===== > def bug(): > print 'Bug 5' > ===== > > both in the same directory. > > load showbug.py into idle (0.5) and runit with F5, > > the bug function prints Bug 5 > > Now change bug1.py outside or even with idle, save it. > dates on disk now show bug1.py is newer than bug1.pyc > > rerun showbug.py pressing F5 or ctrl-F5 > > it still prints Bug 5. > > I dont think this behaviour is what is required.Certainly it cost me most > of the afternoon tracking down non-existant problems in my code. I appreciate the bug report. The current definitions of running a script and importing a module all conspire to get this behavior. We're working on a major change where IDLE executes your script in a separate process that is created from scratch each time you use [ctrl-]F5, and then it will go away. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@mojam.com Fri Apr 28 22:00:41 2000 From: skip@mojam.com (skip@mojam.com) Date: Fri, 28 Apr 2000 17:00:41 -0400 (EDT) Subject: [Python-bugs-list] KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Message-ID: <20000428210041.A4D2D1CD80@dinsdale.python.org> Full_Name: Skip Montanaro Version: 1.5.2, 1.6a2 OS: Linux Submission from: beluga.mojam.com (199.249.165.173) If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the interpreter exits instead of returning you to the top-level prompt. % python Python 1.5.2+ (#12, Feb 17 2000, 14:52:05) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... % PYTHONSTARTUP= ./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... When run under gdb's control, you can see what's happening: % gdb ./python GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... (gdb) set env PYTHONSTARTUP "" (gdb) run Starting program: /home/beluga/skip/src/python/dist/src/./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... Program received signal SIGINT, Interrupt. 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) bt #0 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) c Continuing. File "", line 2 ^ SyntaxError: invalid syntax >>> It appears that SIGINT isn't handled properly when awaiting console input in certain circumstances. If you can entice the program to continue, things work okay. I don't know interrupt handling from a hole in the ground or I'd investigate further. It is quite annoying, especially considering that Python's input history isn't continuous across sessions... Skip