From nobody@sourceforge.net Thu Mar 1 03:18:49 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 19:18:49 -0800 Subject: [Patches] [ python-Patches-404924 ] Cygwin termios module patch Message-ID: Patches #404924, was updated on 2001-02-28 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404924&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Fred L. Drake, Jr. Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404924, was updated on 2001-02-28 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404924&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: Fred L. Drake, Jr. Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Nobody/Anonymous Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From nobody@sourceforge.net Thu Mar 1 06:09:12 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 22:09:12 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Nobody/Anonymous Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From nobody@sourceforge.net Thu Mar 1 08:42:35 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 00:42:35 -0800 Subject: [Patches] [ python-Patches-404826 ] urllib2 enhancements Message-ID: Patches #404826, was updated on 2001-02-28 01:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 Category: library Group: None Status: Open Priority: 3 Submitted By: Moshe Zadka Assigned to: Fred L. Drake, Jr. Summary: urllib2 enhancements Initial Comment: This are some enhancements and bug fixes to urllib2: * Documentation * Better proxy support, including authentication * HTTPS support ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 00:42 Message: Logged In: YES user_id=11645 Checked in as urllib2.py -- 1.9 liburllib2.tex -- 1.1 Fred, can you add the line \input{liburllib2} wherever you feel appropriate (I'd suggest after \input{liburllib} ;-) and close the patch? Thanks. ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-28 12:00 Message: Logged In: YES user_id=31392 I did a cursory review of the patch and it looks good, particularly the documentation! I would prefer to see this included in the beta. Since there was no documentation before, I don't think there's any problem changing the code. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-02-28 02:31 Message: Logged In: YES user_id=11645 I'm having troubles attaching a file, I've put it up at http://www.lerner.co.il/~moshez/urllib2.py.patch (If anyone manages to attach it, I'll be greateful) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 From nobody@sourceforge.net Thu Mar 1 08:47:48 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 00:47:48 -0800 Subject: [Patches] [ python-Patches-404564 ] tempfile.py: Change order of tmp dirs Message-ID: Patches #404564, was updated on 2001-02-27 05:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Gregor Hoffleit Assigned to: Nobody/Anonymous Summary: tempfile.py: Change order of tmp dirs Initial Comment: [cf. Debian bug#87538, http://bugs.debian.org/87538] Please change the order of the dirs in the attemptdirs list in Lib/tempfile.py. It seems more reasonable according to the FHS (File System Hierarchy Standard), if '/tmp' would precede '/var/tmp': attempdirs = ['/tmp', '/var/tmp', '/usr/tmp', pwd] '/var/tmp' was added recently to the list (Aug 2000, 'Patch by tg@FreeBSD.org to try /var/tmp first. This helps on 4.4BSD-based systems.'). I guess it would make no difference if '/var/tmp' would only tried after '/tmp'. In the words of James Troup : "Well... o /var/tmp/ (at least on Debian) is not cleaned on start-up like /tmp is o /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp o it's not documented o it's unexpected I think a better question might be: what's the advantage of the change? *shrug*" ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 00:47 Message: Logged In: YES user_id=11645 Re: cleanup On Solaris, a tmpwatch script is constantly running and cleans up /tmp from things it thinks are too old, if I remember correctly. In any place, /tmp is often cleaned up on reboot automagically -- when it's a ramdisk (I think AIX does this). It seems more reasonable to put /tmp before /var/tmp given that applications that will want to put files in /var/tmp specifically will do so, while /tmp is not supposed to be used before considering local information, so applications that do that will use tempfile. The discussion has gone way, way, off topic. I say check this in. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 09:16 Message: Logged In: YES user_id=44345 Then the standard is wrong. ;-) I will rephrase: Any system that relies on boot-time cleanup to keep a disk partition from filling up is broken. /tmp is generally on the root partition, the partition that is most dangerous to allow to fill. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit Date: 2001-02-27 08:03 Message: Logged In: YES user_id=5293 Regarding your statement: "If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp." The Linux Standard Base (more specifically: the File System Hierarchy) says this about /var/tmp: 5.12 /var/tmp : Temporary files preserved between system reboots The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. Therefore, if you setup your system to remove files in /var/tmp on reboot, your system will not be compliant with the Linux standard. Moreover, the description for /tmp seems more appropriate for tempfile IMHO: 3.11 /tmp : Temporary files The /tmp directory shall be made available for programs that require temporary files. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Programs shall not assume that any files or directories in /tmp are preserved between invocations of the program. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 07:46 Message: Logged In: YES user_id=44345 Regarding this statement: /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp It is a red herring. /var is often given it's own separate partition precisely because the / partition is often very small. I think /var/tmp should appear before /tmp. If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp. After all, who cares about cleanup at reboot on systems that can remain up for more than a year? What do you think this is - Windows? ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 From nobody@sourceforge.net Thu Mar 1 09:17:23 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 01:17:23 -0800 Subject: [Patches] [ python-Patches-403678 ] setup.py.in Message-ID: Patches #403678, was updated on 2001-02-07 22:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403678&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Donn Cave Assigned to: A.M. Kuchling Summary: setup.py.in Initial Comment: (Obsoletes part of #103487) Use the "configure" procedure for platform specific values in setup.py. Build setup.py from setup.py.in - setup.cfg.in was a nuisance anyway. The particular configure options for setup.py in this patch are for BeOS, but it would be worth a look to see if some or all of the USE_xxx options there should get in there, especially if controlled by --with-xxx flags. ---------------------------------------------------------------------- Comment By: The Written Word (china) Date: 2001-03-01 01:17 Message: Logged In: YES user_id=119770 I agree with donnc. We should definitely try and remove platform-specific items, hard-coded paths, etc. from setup.py. Let autoconf handle that. setup.py should be dumb and driven by autoconf. We just ran into a situation where we tried building 2.1CVS and wanted to feed -DUSE_SSL to Modules/socketmodule.c. We're on a Solaris machine which doesn't have libssl and libcrypto in the system linker search path. So, we have to add -I and -L options to the cc and ld line when Modules/socketmodule.c is built. How do we do this with setup.py? Dunno. We currently have a hack around this. I'd like a --with-ssl= to configure this at ./configure time and have that get passed on to setup.py. Ditto for tk. And, hard-coding /usr/local/include and /usr/local/lib is just ugly. Also, termios does not build "out of the box" under Solaris. How do we disable this module? ---------------------------------------------------------------------- Comment By: Donn Cave Date: 2001-02-23 10:22 Message: Yes, it's still waiting to be resolved. The patch at least illustrates the problems (and of course it would also solve them if applied.) I have been hoping that you would put some thought into it, since your sense of direction on it is at least clear enough to know that it's different from where I would go. Since there's plenty of specific information about what needs to be done, I would prefer that you do at least something for it, in setup.py. Then after you have wrestled with the issues, I can check it out and see what you came up with, and if necessary straighten out anything that doesn't actually work. If you want, I might be able to take a look at what it would take to remove every single directory path literal ('/usr/X11R5', '/usr/lib/termcap', etc.), every platform literal ('aix', 'sunos5', etc.) and every reference to a platform specific flag ("linker_so + ' -shared' - what's up with that?) and put it in configure if it's really needed at all. Don't know if I could get that done for 2.1a3, but the sooner that gets cleaned up the better. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-23 08:37 Message: Donn, is this patch still relevant? Do there remain BeOS-specific issues to fix? Probably separate patches and bugs should be opened to handle any outstanding problems. ---------------------------------------------------------------------- Comment By: Donn Cave Date: 2001-02-08 15:43 Message: Not worried, just was trying to point out the good side of a throw-away system for the dirty business of platform warts. Anyway, with all that stuff to get done in setup.py, obviously the release is a ways off yet. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg Date: 2001-02-08 14:51 Message: Na, it's not higher, only in this case, the design is going in the wrong direction. The new setup.py mechanism was meant to allow as much automatic configuration as possible (previously people had to edit Modules/Setup which was not difficult, but obscure enough to keep people from enabling important add-ons such as Tkinter). Now with the setup.py auto-detection mechanisms in place, there should be much less user interaction required to get a fully functional system. As for the other patches: many of the Python core team are currently out of town so there's a natural delay there. Nothing to worry about though. ---------------------------------------------------------------------- Comment By: Donn Cave Date: 2001-02-08 11:16 Message: I would be happy with extra symbols in Makefile, for setup.py to use. I think this system will be somewhat obscure for someone trying to figure out how to make a build work, so some pointer comments at the top of setup.py would be good. The last point there is not so clear to me -- it sounds like there's an intent to move a lot of logic from "configure" to setup.py. I look forward to seeing whether that does give us much more power and flexibility. It will put some pressure on the Python code base, though - I already have changes in for distutils and even os.py, to get through the build, not to mention the two unsuccessful attempts to get changes into setup.py. In 2.0, I came along pretty late in the beta with changes that make it build for BeOS. Here I am right at the beginning of 2.1 alpha, but the hurdle seems a lot higher. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-08 10:45 Message: One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg Date: 2001-02-08 10:29 Message: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ---------------------------------------------------------------------- Comment By: Donn Cave Date: 2001-02-08 10:12 Message: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-08 08:38 Message: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg Date: 2001-02-08 05:01 Message: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403678&group_id=5470 From nobody@sourceforge.net Thu Mar 1 09:35:08 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 01:35:08 -0800 Subject: [Patches] [ python-Patches-405092 ] Modules/termios.c on Solaris 2.6/SPARC Message-ID: Patches #405092, was updated on 2001-03-01 01:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: The Written Word (china) Assigned to: Nobody/Anonymous Summary: Modules/termios.c on Solaris 2.6/SPARC Initial Comment: Modules/termios.c does not build "out of the box" under Solaris 2.6/SPARC because some values are undefined. The attached patch fixes this. This leaves one error: cc -mr -Qn -xO2 -xtarget=generic -I. -I/opt/build/python-2.1/./Include -IInclude/ -I/usr/local/include -c /opt/build/python-2.1/Modules/termios.c -o build/temp.solaris-2.6-sun4u-2.1/termios.o "/opt/build/python-2.1/Modules/termios.c", line 405: warning: initializer does not fit or is out of range: 0x80000000 The value of CRTSCTS in is: #define CRTSCTS 020000000000 which does not fit in a "long": static struct constant { char *name; long value; } termios_constants[] = { Changing value to 'unsigned long' fixes this but I do not know what repercussions this will have. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 From nobody@sourceforge.net Thu Mar 1 10:55:01 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 02:55:01 -0800 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Moshe Zadka Assigned to: A.M. Kuchling Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 From nobody@sourceforge.net Thu Mar 1 10:55:37 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 02:55:37 -0800 Subject: [Patches] [ python-Patches-405102 ] os.py: fix docstring (make raw) Message-ID: Patches #405102, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Nobody/Anonymous Summary: os.py: fix docstring (make raw) Initial Comment: The docstring for os contains sequences like '\r' that become real control characters; using r""" instead of """ makes the docstring read correctly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 From nobody@sourceforge.net Thu Mar 1 10:58:26 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 02:58:26 -0800 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Moshe Zadka Assigned to: A.M. Kuchling Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 02:58 Message: Logged In: YES user_id=11645 Well, as usual, the attachment did not work. Available as http://www.lerner.co.il/~moshez/ssl_seed Also put here for reference purposes: Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 10:38:45 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2503 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + srand(time(NULL)); + for(i=0; i Patches #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Moshe Zadka Assigned to: A.M. Kuchling Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 03:01 Message: Logged In: YES user_id=11645 Note: the patch survived remarkably well: The only broken lines are the one that goes: (PyObject *)&SSL_Type) != And the one that goes: RAND_seed(random_string, ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 02:58 Message: Logged In: YES user_id=11645 Well, as usual, the attachment did not work. Available as http://www.lerner.co.il/~moshez/ssl_seed Also put here for reference purposes: Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 10:38:45 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2503 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + srand(time(NULL)); + for(i=0; i Patches #405102, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Nobody/Anonymous Summary: os.py: fix docstring (make raw) Initial Comment: The docstring for os contains sequences like '\r' that become real control characters; using r""" instead of """ makes the docstring read correctly. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 03:02 Message: Logged In: YES user_id=11645 As usual, the file was not attached. Ping, can you please put it up somewhere, and give the URL in a comment? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 From nobody@sourceforge.net Thu Mar 1 11:40:59 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 03:40:59 -0800 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Moshe Zadka Assigned to: A.M. Kuchling Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches #405122, was updated on 2001-03-01 06:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Eric S. Raymond Summary: webbrowser fix Initial Comment: Put the word "Web" in the synopsis line. Remove the -no-about-splash option, as it prevents this module from working with Netscape 3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 From nobody@sourceforge.net Thu Mar 1 15:20:29 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 07:20:29 -0800 Subject: [Patches] [ python-Patches-405139 ] Add reset() method to dircache Message-ID: Patches #405139, was updated on 2001-03-01 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Itamar S.T. Assigned to: Nobody/Anonymous Summary: Add reset() method to dircache Initial Comment: The statcache module has a method reset() that resets the cache. The dircache module does not. This simple patch (basically a copy/paste from statcache) adds a reset() method to the dircache module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 From nobody@sourceforge.net Thu Mar 1 17:44:01 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 09:44:01 -0800 Subject: [Patches] [ python-Patches-405122 ] webbrowser fix Message-ID: Patches #405122, was updated on 2001-03-01 06:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Eric S. Raymond Summary: webbrowser fix Initial Comment: Put the word "Web" in the synopsis line. Remove the -no-about-splash option, as it prevents this module from working with Netscape 3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 From nobody@sourceforge.net Thu Mar 1 18:42:41 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 10:42:41 -0800 Subject: [Patches] [ python-Patches-405122 ] webbrowser fix Message-ID: Patches #405122, was updated on 2001-03-01 06:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Eric S. Raymond Summary: webbrowser fix Initial Comment: Put the word "Web" in the synopsis line. Remove the -no-about-splash option, as it prevents this module from working with Netscape 3. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 10:42 Message: Logged In: YES user_id=6380 Fixing ESR's finger error -- don't reject this yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 From nobody@sourceforge.net Thu Mar 1 18:51:04 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 10:51:04 -0800 Subject: [Patches] [ python-Patches-405122 ] webbrowser fix Message-ID: Patches #405122, was updated on 2001-03-01 06:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Eric S. Raymond Summary: webbrowser fix Initial Comment: Put the word "Web" in the synopsis line. Remove the -no-about-splash option, as it prevents this module from working with Netscape 3. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 10:42 Message: Logged In: YES user_id=6380 Fixing ESR's finger error -- don't reject this yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 From nobody@sourceforge.net Thu Mar 1 18:52:57 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 10:52:57 -0800 Subject: [Patches] [ python-Patches-402357 ] Add support for frameworks and objective-c source. Uesful for both GnuStep and for OSXS/OSX/Darwin. Message-ID: Patches #402357, was updated on 2000-11-11 00:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402357&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Bill Bumgarner Assigned to: Guido van Rossum Summary: Add support for frameworks and objective-c source. Uesful for both GnuStep and for OSXS/OSX/Darwin. Initial Comment: ---------------------------------------------------------------------- Comment By: Bill Bumgarner Date: 2001-03-01 10:52 Message: Logged In: YES user_id=103811 It should use the normal CC referenced compiler as ObjC is integrated directly into gcc and enabled through the use of the -ObjC flag. Index: makesetup =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/makesetup,v retrieving revision 1.34 diff -r1.34 makesetup 207c207 < *.m) obj=`basename $src .m`.o; cc='$(CXX)';; # Obj-C --- > *.m) obj=`basename $src .m`.o; cc='$(CC)';; # Obj-C Thank you. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-01-10 13:46 Message: Applied. Again, somehow the line numbers in your diff were broken! I've changed $(CCC) to $(CXX) since that is now the name of the C++ compiler. If this wasn't what you intended, please get in touch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402357&group_id=5470 From nobody@sourceforge.net Thu Mar 1 19:26:47 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 11:26:47 -0800 Subject: [Patches] [ python-Patches-405228 ] split Telnet class into TelnetBase Message-ID: Patches #405228, was updated on 2001-03-01 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Luke Kenneth Casson Leighton Assigned to: Nobody/Anonymous Summary: split Telnet class into TelnetBase Initial Comment: I've been asked to make telnet, ssh, bash and rpcclient (http://www.samba-tng.org), http requests and possibly much more all look seamlessly like telnet. That means splitting telnetlib.py's Telnet class down into a base class. I need the write, read_until, expect and friends, but did not want to do a total rewrite / total pain-in-the-neck cut/paste job on telnetlib.py just to fulfil the requirements. I have noticed that someone wrote an scp class, already before: it's available on parnassus. it wraps scp in popen. with this TelnetBase class, doing the same thing will be trivial _and_ you get the exact same look and functionality as if it was a Telnet() instance. well, it makes _me_ happy enough to submit this patch. copyright is hereby assigned to Guido van Rossum. authorship must remain as-is. have fun, luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 From nobody@sourceforge.net Thu Mar 1 19:32:06 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 11:32:06 -0800 Subject: [Patches] [ python-Patches-405228 ] split Telnet class into TelnetBase Message-ID: Patches #405228, was updated on 2001-03-01 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Luke Kenneth Casson Leighton Assigned to: Nobody/Anonymous Summary: split Telnet class into TelnetBase Initial Comment: I've been asked to make telnet, ssh, bash and rpcclient (http://www.samba-tng.org), http requests and possibly much more all look seamlessly like telnet. That means splitting telnetlib.py's Telnet class down into a base class. I need the write, read_until, expect and friends, but did not want to do a total rewrite / total pain-in-the-neck cut/paste job on telnetlib.py just to fulfil the requirements. I have noticed that someone wrote an scp class, already before: it's available on parnassus. it wraps scp in popen. with this TelnetBase class, doing the same thing will be trivial _and_ you get the exact same look and functionality as if it was a Telnet() instance. well, it makes _me_ happy enough to submit this patch. copyright is hereby assigned to Guido van Rossum. authorship must remain as-is. have fun, luke ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton Date: 2001-03-01 11:32 Message: Logged In: YES user_id=80200 good grief. what the hell is wrong with sourceforge??? you can't upload files! grrr. diff -u will be sent to patches@python.org. grrr ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 From lkcl@samba-tng.org Thu Mar 1 19:18:53 2001 From: lkcl@samba-tng.org (Luke Kenneth Casson Leighton) Date: Fri, 2 Mar 2001 06:18:53 +1100 Subject: [Patches] Re: [ python-Patches-405228 ] split Telnet class into TelnetBase In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---888078244-1906648092-983474333=:14207 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 1 Mar 2001, nobody wrote: > Patches #405228, was updated on 2001-03-01 11:26 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 > > Category: library > Group: None > Status: Open > Priority: 5 > Submitted By: Luke Kenneth Casson Leighton > Assigned to: Nobody/Anonymous > Summary: split Telnet class into TelnetBase > > Initial Comment: > I've been asked to make telnet, ssh, bash and rpcclient > (http://www.samba-tng.org), http requests and possibly > much more all look seamlessly like telnet. > > That means splitting telnetlib.py's Telnet class down > into a base class. I need the write, read_until, > expect and friends, but did not want to do a total > rewrite / total pain-in-the-neck cut/paste job on > telnetlib.py just to fulfil the requirements. > > I have noticed that someone wrote an scp class, already > before: it's available on parnassus. it wraps scp in > popen. with this TelnetBase class, doing the same > thing will be trivial _and_ you get the exact same look > and functionality as if it was a Telnet() instance. > > well, it makes _me_ happy enough to submit this patch. > > copyright is hereby assigned to Guido van Rossum. > authorship must remain as-is. > > have fun, > > luke > > ---------------------------------------------------------------------- > > Comment By: Luke Kenneth Casson Leighton > Date: 2001-03-01 11:32 > > Message: > Logged In: YES > user_id=80200 > > good grief. what the hell is wrong with sourceforge??? you > can't upload files! grrr. diff -u will be sent to > patches@python.org. grrr > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 > ----- Luke Kenneth Casson Leighton ----- "i want a world of dreams, run by near-sighted visionaries" "good. that's them sorted out. now, on _this_ world..." ---888078244-1906648092-983474333=:14207 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="f.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="f.txt" LS0tIC91c3IvbG9jYWwvbGliL3B5dGhvbjIuMC90ZWxuZXRsaWIucHkJVHVl IEZlYiAyNyAxNjowODowNyAyMDAxDQorKysgdGVsbmV0bGliMi5weQlUaHUg TWFyICAxIDIwOjE5OjA0IDIwMDENCkBAIC0zMyw2ICszMywyMyBAQA0KIC0g dGltZW91dCBzaG91bGQgYmUgaW50cmluc2ljIHRvIHRoZSBjb25uZWN0aW9u IG9iamVjdCBpbnN0ZWFkIG9mIGFuDQogICBvcHRpb24gb24gb25lIG9mIHRo ZSByZWFkIGNhbGxzIG9ubHkNCiANCitNb2RpZmljYXRpb25zOg0KKzEgTWFy IDIwMDEgIEF1dGhvcjogTHVrZSBLZW5uZXRoIENhc3NvbiBMZWlnaHRvbiA8 bGtjbEBzYW1iYS10bmcub3JnPg0KKw0KK1RlbG5ldEJhc2UgLSBzcGxpdCBU ZWxuZXQgaW50byBiYXNlIGNsYXNzIHRvIGFsbG93IG90aGVyDQorInRlbG5l dC1saWtlIiBiYXNlIGNsYXNzZXMgdG8gYmUgdHJhbnNwYXJlbnRseSBjcmVh dGVkLg0KKw0KK0ZvciBleGFtcGxlLCBhIFRlbG5ldFBvcGVuMyBjbGFzcyB0 aGF0IHRha2VzIGEgY29tbWFuZCBhcw0KK2l0cy4uLiB1bS4uLiBob3N0IGFy Z3VtZW50IChlLmcuIHRvIHNzaCkgd2hpY2ggdGhlbiBiZWhhdmVzDQorZXhh Y3RseSBhcyB0aGUgVGVsbmV0IGNsYXNzIGRvZXMgZXhjZXB0IGl0J3Mgc3No LiAgIE9yIHRoaXM6DQorVGVsbmV0UG9wZW4zKCIvYmluL2Jhc2giKS4NCisN CitGb3IgZXhhbXBsZSwgYSBUZWxuZXRIVFRQIGNsYXNzIHRoYXQgd3JhcHMg SFRUUCByZXF1ZXN0cywNCithbmQgdHJlYXRzIHRoZW0gYXMgd3JpdGUgY29t bWFuZHMsIHdoaWNoIGFsbG93cyB5b3UgdG8gcGVyZm9ybQ0KK2V4cGVjdCBh bmQgcmVhZF91bnRpbCBhbmQgZnJpZW5kcyBvbiB0aGUgSFRUUCByZXNwb25z ZSENCisNCitPciBhbnkgb3RoZXIgcHJvdG9jb2wuICBPciwgaG93IGFib3V0 IFRlbG5ldFVuaXhEb21haW5Tb2NrZXQoKT8NCisNCiAiIiINCiANCiANCkBA IC00NSwzMCArNjIsMTUgQEANCiAjIFR1bmFibGUgcGFyYW1ldGVycw0KIERF QlVHTEVWRUwgPSAwDQogDQotIyBUZWxuZXQgcHJvdG9jb2wgZGVmYXVsdHMN Ci1URUxORVRfUE9SVCA9IDIzDQotDQotIyBUZWxuZXQgcHJvdG9jb2wgY2hh cmFjdGVycyAoZG9uJ3QgY2hhbmdlKQ0KLUlBQyAgPSBjaHIoMjU1KSAjICJJ bnRlcnByZXQgQXMgQ29tbWFuZCINCi1ET05UID0gY2hyKDI1NCkNCi1ETyAg ID0gY2hyKDI1MykNCi1XT05UID0gY2hyKDI1MikNCi1XSUxMID0gY2hyKDI1 MSkNCi10aGVOVUxMID0gY2hyKDApDQotDQotDQotY2xhc3MgVGVsbmV0Og0K K2NsYXNzIFRlbG5ldEJhc2U6DQogDQotICAgICIiIlRlbG5ldCBpbnRlcmZh Y2UgY2xhc3MuDQotDQotICAgIEFuIGluc3RhbmNlIG9mIHRoaXMgY2xhc3Mg cmVwcmVzZW50cyBhIGNvbm5lY3Rpb24gdG8gYSB0ZWxuZXQNCi0gICAgc2Vy dmVyLiAgVGhlIGluc3RhbmNlIGlzIGluaXRpYWxseSBub3QgY29ubmVjdGVk OyB0aGUgb3BlbigpDQotICAgIG1ldGhvZCBtdXN0IGJlIHVzZWQgdG8gZXN0 YWJsaXNoIGEgY29ubmVjdGlvbi4gIEFsdGVybmF0aXZlbHksIHRoZQ0KLSAg ICBob3N0IG5hbWUgYW5kIG9wdGlvbmFsIHBvcnQgbnVtYmVyIGNhbiBiZSBw YXNzZWQgdG8gdGhlDQotICAgIGNvbnN0cnVjdG9yLCB0b28uDQotDQotICAg IERvbid0IHRyeSB0byByZW9wZW4gYW4gYWxyZWFkeSBjb25uZWN0ZWQgaW5z dGFuY2UuDQorICAgICIiIlRlbG5ldEJhc2UgaW50ZXJmYWNlIGNsYXNzLg0K IA0KKyAgICBBbiBpbnN0YW5jZSBvZiB0aGlzIGNsYXNzIHJlcHJlc2VudHMg YSBjb25uZWN0aW9uIHRvIHNvbWV0aGluZw0KKwlyZXNlbWJsaW5nIGEgdGVs bmV0IHNlcnZlci4gIEZvciBleGFtcGxlLCBhIHBvcGVuMyB0byBhIGNvbW1h bmQNCisJc3VjaCBhcyBzc2ggY291bGQgYmUgcGVyZm9ybWVkLCBvciBpZiB5 b3UgYXJlIGZlZWxpbmcgdXAgdG8gaXQsDQorCWNvbWJpbmUgVGVsbmV0QmFz ZSB3aXRoIEhUVFBDb25uZWN0aW9uIQ0KKwkNCiAgICAgVGhpcyBjbGFzcyBo YXMgbWFueSByZWFkXyooKSBtZXRob2RzLiAgTm90ZSB0aGF0IHNvbWUgb2Yg dGhlbQ0KICAgICByYWlzZSBFT0ZFcnJvciB3aGVuIHRoZSBlbmQgb2YgdGhl IGNvbm5lY3Rpb24gaXMgcmVhZCwgYmVjYXVzZQ0KICAgICB0aGV5IGNhbiBy ZXR1cm4gYW4gZW1wdHkgc3RyaW5nIGZvciBvdGhlciByZWFzb25zLiAgU2Vl IHRoZQ0KQEAgLTEzMCwxNyArMTMyLDExIEBADQogICAgICAgICBEb24ndCB0 cnkgdG8gcmVvcGVuIGFuIGFscmVhZHkgY29ubmVjdGVkIGluc3RhbmNlLg0K IA0KICAgICAgICAgIiIiDQotICAgICAgICBzZWxmLmVvZiA9IDANCi0gICAg ICAgIGlmIG5vdCBwb3J0Og0KLSAgICAgICAgICAgIHBvcnQgPSBURUxORVRf UE9SVA0KLSAgICAgICAgc2VsZi5ob3N0ID0gaG9zdA0KLSAgICAgICAgc2Vs Zi5wb3J0ID0gcG9ydA0KLSAgICAgICAgc2VsZi5zb2NrID0gc29ja2V0LnNv Y2tldChzb2NrZXQuQUZfSU5FVCwgc29ja2V0LlNPQ0tfU1RSRUFNKQ0KLSAg ICAgICAgc2VsZi5zb2NrLmNvbm5lY3QoKHNlbGYuaG9zdCwgc2VsZi5wb3J0 KSkNCisgICAgICAgIHBhc3MNCiANCiAgICAgZGVmIF9fZGVsX18oc2VsZik6 DQogICAgICAgICAiIiJEZXN0cnVjdG9yIC0tIGNsb3NlIHRoZSBjb25uZWN0 aW9uLiIiIg0KLSAgICAgICAgc2VsZi5jbG9zZSgpDQorICAgICAgICBwYXNz DQogDQogICAgIGRlZiBtc2coc2VsZiwgbXNnLCAqYXJncyk6DQogICAgICAg ICAiIiJQcmludCBhIGRlYnVnIG1lc3NhZ2UsIHdoZW4gdGhlIGRlYnVnIGxl dmVsIGlzID4gMC4NCkBAIC0xNjYsMTggKzE2Miw3IEBADQogDQogICAgIGRl ZiBjbG9zZShzZWxmKToNCiAgICAgICAgICIiIkNsb3NlIHRoZSBjb25uZWN0 aW9uLiIiIg0KLSAgICAgICAgaWYgc2VsZi5zb2NrOg0KLSAgICAgICAgICAg IHNlbGYuc29jay5jbG9zZSgpDQotICAgICAgICBzZWxmLnNvY2sgPSAwDQot ICAgICAgICBzZWxmLmVvZiA9IDENCi0NCi0gICAgZGVmIGdldF9zb2NrZXQo c2VsZik6DQotICAgICAgICAiIiJSZXR1cm4gdGhlIHNvY2tldCBvYmplY3Qg dXNlZCBpbnRlcm5hbGx5LiIiIg0KLSAgICAgICAgcmV0dXJuIHNlbGYuc29j aw0KLQ0KLSAgICBkZWYgZmlsZW5vKHNlbGYpOg0KLSAgICAgICAgIiIiUmV0 dXJuIHRoZSBmaWxlbm8oKSBvZiB0aGUgc29ja2V0IG9iamVjdCB1c2VkIGlu dGVybmFsbHkuIiIiDQotICAgICAgICByZXR1cm4gc2VsZi5zb2NrLmZpbGVu bygpDQorICAgICAgICBwYXNzDQogDQogICAgIGRlZiB3cml0ZShzZWxmLCBi dWZmZXIpOg0KICAgICAgICAgIiIiV3JpdGUgYSBzdHJpbmcgdG8gdGhlIHNv Y2tldCwgZG91YmxpbmcgYW55IElBQyBjaGFyYWN0ZXJzLg0KQEAgLTE4Niwx MCArMTcxLDcgQEANCiAgICAgICAgIHNvY2tldC5lcnJvciBpZiB0aGUgY29u bmVjdGlvbiBpcyBjbG9zZWQuDQogDQogICAgICAgICAiIiINCi0gICAgICAg IGlmIElBQyBpbiBidWZmZXI6DQotICAgICAgICAgICAgYnVmZmVyID0gc3Ry aW5nLnJlcGxhY2UoYnVmZmVyLCBJQUMsIElBQytJQUMpDQotICAgICAgICBz ZWxmLm1zZygic2VuZCAlcyIsIGBidWZmZXJgKQ0KLSAgICAgICAgc2VsZi5z b2NrLnNlbmQoYnVmZmVyKQ0KKyAgICAgICAgcGFzcw0KIA0KICAgICBkZWYg cmVhZF91bnRpbChzZWxmLCBtYXRjaCwgdGltZW91dD1Ob25lKToNCiAgICAg ICAgICIiIlJlYWQgdW50aWwgYSBnaXZlbiBzdHJpbmcgaXMgZW5jb3VudGVy ZWQgb3IgdW50aWwgdGltZW91dC4NCkBAIC0zMDcsNiArMjg5LDE3NyBAQA0K ICAgICAgICAgdGhlIG1pZHN0IG9mIGFuIElBQyBzZXF1ZW5jZS4NCiANCiAg ICAgICAgICIiIg0KKyAgICAgICAgcGFzcw0KKw0KKyAgICBkZWYgcmF3cV9n ZXRjaGFyKHNlbGYpOg0KKyAgICAgICAgIiIiR2V0IG5leHQgY2hhciBmcm9t IHJhdyBxdWV1ZS4NCisNCisgICAgICAgIEJsb2NrIGlmIG5vIGRhdGEgaXMg aW1tZWRpYXRlbHkgYXZhaWxhYmxlLiAgUmFpc2UgRU9GRXJyb3INCisgICAg ICAgIHdoZW4gY29ubmVjdGlvbiBpcyBjbG9zZWQuDQorDQorICAgICAgICAi IiINCisgICAgICAgIGlmIG5vdCBzZWxmLnJhd3E6DQorICAgICAgICAgICAg c2VsZi5maWxsX3Jhd3EoKQ0KKyAgICAgICAgICAgIGlmIHNlbGYuZW9mOg0K KyAgICAgICAgICAgICAgICByYWlzZSBFT0ZFcnJvcg0KKyAgICAgICAgYyA9 IHNlbGYucmF3cVtzZWxmLmlyYXdxXQ0KKyAgICAgICAgc2VsZi5pcmF3cSA9 IHNlbGYuaXJhd3EgKyAxDQorICAgICAgICBpZiBzZWxmLmlyYXdxID49IGxl bihzZWxmLnJhd3EpOg0KKyAgICAgICAgICAgIHNlbGYucmF3cSA9ICcnDQor ICAgICAgICAgICAgc2VsZi5pcmF3cSA9IDANCisgICAgICAgIHJldHVybiBj DQorDQorICAgIGRlZiBmaWxsX3Jhd3Eoc2VsZik6DQorICAgICAgICAiIiJG aWxsIHJhdyBxdWV1ZSBmcm9tIGV4YWN0bHkgb25lIHJlY3YoKSBzeXN0ZW0g Y2FsbC4NCisNCisgICAgICAgIEJsb2NrIGlmIG5vIGRhdGEgaXMgaW1tZWRp YXRlbHkgYXZhaWxhYmxlLiAgU2V0IHNlbGYuZW9mIHdoZW4NCisgICAgICAg IGNvbm5lY3Rpb24gaXMgY2xvc2VkLg0KKw0KKyAgICAgICAgIiIiDQorICAg ICAgICBwYXNzDQorDQorICAgIGRlZiBzZWxlY3Qoc2VsZik6DQorICAgICAg ICAiIiJUZXN0IHdoZXRoZXIgZGF0YSBpcyBhdmFpbGFibGUgb24gdGhlIHNv Y2tldC4iIiINCisgICAgICAgIHBhc3MNCisNCisgICAgZGVmIHNvY2tfYXZh aWwoc2VsZik6DQorICAgICAgICAiIiJUZXN0IHdoZXRoZXIgZGF0YSBpcyBh dmFpbGFibGUgb24gdGhlIHNvY2tldC4iIiINCisgICAgICAgIHBhc3MNCisN CisgICAgZGVmIGV4cGVjdChzZWxmLCBsaXN0LCB0aW1lb3V0PU5vbmUpOg0K KyAgICAgICAgIiIiUmVhZCB1bnRpbCBvbmUgZnJvbSBhIGxpc3Qgb2YgYSBy ZWd1bGFyIGV4cHJlc3Npb25zIG1hdGNoZXMuDQorDQorICAgICAgICBUaGUg Zmlyc3QgYXJndW1lbnQgaXMgYSBsaXN0IG9mIHJlZ3VsYXIgZXhwcmVzc2lv bnMsIGVpdGhlcg0KKyAgICAgICAgY29tcGlsZWQgKHJlLlJlZ2V4T2JqZWN0 IGluc3RhbmNlcykgb3IgdW5jb21waWxlZCAoc3RyaW5ncykuDQorICAgICAg ICBUaGUgb3B0aW9uYWwgc2Vjb25kIGFyZ3VtZW50IGlzIGEgdGltZW91dCwg aW4gc2Vjb25kczsgZGVmYXVsdA0KKyAgICAgICAgaXMgbm8gdGltZW91dC4N CisNCisgICAgICAgIFJldHVybiBhIHR1cGxlIG9mIHRocmVlIGl0ZW1zOiB0 aGUgaW5kZXggaW4gdGhlIGxpc3Qgb2YgdGhlDQorICAgICAgICBmaXJzdCBy ZWd1bGFyIGV4cHJlc3Npb24gdGhhdCBtYXRjaGVzOyB0aGUgbWF0Y2ggb2Jq ZWN0DQorICAgICAgICByZXR1cm5lZDsgYW5kIHRoZSB0ZXh0IHJlYWQgdXAg dGlsbCBhbmQgaW5jbHVkaW5nIHRoZSBtYXRjaC4NCisNCisgICAgICAgIElm IEVPRiBpcyByZWFkIGFuZCBubyB0ZXh0IHdhcyByZWFkLCByYWlzZSBFT0ZF cnJvci4NCisgICAgICAgIE90aGVyd2lzZSwgd2hlbiBub3RoaW5nIG1hdGNo ZXMsIHJldHVybiAoLTEsIE5vbmUsIHRleHQpIHdoZXJlDQorICAgICAgICB0 ZXh0IGlzIHRoZSB0ZXh0IHJlY2VpdmVkIHNvIGZhciAobWF5IGJlIHRoZSBl bXB0eSBzdHJpbmcgaWYgYQ0KKyAgICAgICAgdGltZW91dCBoYXBwZW5lZCku DQorDQorICAgICAgICBJZiBhIHJlZ3VsYXIgZXhwcmVzc2lvbiBlbmRzIHdp dGggYSBncmVlZHkgbWF0Y2ggKGUuZy4gJy4qJykNCisgICAgICAgIG9yIGlm IG1vcmUgdGhhbiBvbmUgZXhwcmVzc2lvbiBjYW4gbWF0Y2ggdGhlIHNhbWUg aW5wdXQsIHRoZQ0KKyAgICAgICAgcmVzdWx0cyBhcmUgdW5kZXRlcm1pbmlz dGljLCBhbmQgbWF5IGRlcGVuZCBvbiB0aGUgSS9PIHRpbWluZy4NCisNCisg ICAgICAgICIiIg0KKyAgICAgICAgcmUgPSBOb25lDQorICAgICAgICBsaXN0 ID0gbGlzdFs6XQ0KKyAgICAgICAgaW5kaWNlcyA9IHJhbmdlKGxlbihsaXN0 KSkNCisgICAgICAgIGZvciBpIGluIGluZGljZXM6DQorICAgICAgICAgICAg aWYgbm90IGhhc2F0dHIobGlzdFtpXSwgInNlYXJjaCIpOg0KKyAgICAgICAg ICAgICAgICBpZiBub3QgcmU6IGltcG9ydCByZQ0KKyAgICAgICAgICAgICAg ICBsaXN0W2ldID0gcmUuY29tcGlsZShsaXN0W2ldKQ0KKyAgICAgICAgd2hp bGUgMToNCisgICAgICAgICAgICBzZWxmLnByb2Nlc3NfcmF3cSgpDQorICAg ICAgICAgICAgZm9yIGkgaW4gaW5kaWNlczoNCisgICAgICAgICAgICAgICAg bSA9IGxpc3RbaV0uc2VhcmNoKHNlbGYuY29va2VkcSkNCisgICAgICAgICAg ICAgICAgaWYgbToNCisgICAgICAgICAgICAgICAgICAgIGUgPSBtLmVuZCgp DQorICAgICAgICAgICAgICAgICAgICB0ZXh0ID0gc2VsZi5jb29rZWRxWzpl XQ0KKyAgICAgICAgICAgICAgICAgICAgc2VsZi5jb29rZWRxID0gc2VsZi5j b29rZWRxW2U6XQ0KKyAgICAgICAgICAgICAgICAgICAgcmV0dXJuIChpLCBt LCB0ZXh0KQ0KKyAgICAgICAgICAgIGlmIHNlbGYuZW9mOg0KKyAgICAgICAg ICAgICAgICBicmVhaw0KKyAgICAgICAgICAgIGlmIHRpbWVvdXQgaXMgbm90 IE5vbmU6DQorICAgICAgICAgICAgICAgIHIsIHcsIHggPSBzZWxmLnNlbGVj dCh0aW1lb3V0KQ0KKyAgICAgICAgICAgICAgICBpZiBub3QgcjoNCisgICAg ICAgICAgICAgICAgICAgIGJyZWFrDQorICAgICAgICAgICAgc2VsZi5maWxs X3Jhd3EoKQ0KKyAgICAgICAgdGV4dCA9IHNlbGYucmVhZF92ZXJ5X2xhenko KQ0KKyAgICAgICAgaWYgbm90IHRleHQgYW5kIHNlbGYuZW9mOg0KKyAgICAg ICAgICAgIHJhaXNlIEVPRkVycm9yDQorICAgICAgICByZXR1cm4gKC0xLCBO b25lLCB0ZXh0KQ0KKw0KKyMgVGVsbmV0IHByb3RvY29sIGRlZmF1bHRzDQor VEVMTkVUX1BPUlQgPSAyMw0KKw0KKyMgVGVsbmV0IHByb3RvY29sIGNoYXJh Y3RlcnMgKGRvbid0IGNoYW5nZSkNCitJQUMgID0gY2hyKDI1NSkgIyAiSW50 ZXJwcmV0IEFzIENvbW1hbmQiDQorRE9OVCA9IGNocigyNTQpDQorRE8gICA9 IGNocigyNTMpDQorV09OVCA9IGNocigyNTIpDQorV0lMTCA9IGNocigyNTEp DQordGhlTlVMTCA9IGNocigwKQ0KKw0KKw0KK2NsYXNzIFRlbG5ldChUZWxu ZXRCYXNlKToNCisNCisgICAgIiIiVGVsbmV0IGludGVyZmFjZSBjbGFzcy4N CisNCisgICAgQW4gaW5zdGFuY2Ugb2YgdGhpcyBjbGFzcyByZXByZXNlbnRz IGEgY29ubmVjdGlvbiB0byBhIHRlbG5ldA0KKyAgICBzZXJ2ZXIuICBJdCBw cm92aWRlcyBzb2NrZXQtYmFzZWQgZnVuY3Rpb25zIHRoYXQgYXV0b21hdGlj YWxseQ0KKwloYW5kbGUgSUFDIHNlcXVlbmNlcy4gIEl0IGFsc28gbG9va3Mg bGlrZSBhIHNvY2tldCBjbGFzcy4NCisNCisJVGhlIGluc3RhbmNlIGlzIGlu aXRpYWxseSBub3QgY29ubmVjdGVkOyB0aGUgb3BlbigpDQorICAgIG1ldGhv ZCBtdXN0IGJlIHVzZWQgdG8gZXN0YWJsaXNoIGEgY29ubmVjdGlvbi4gIEFs dGVybmF0aXZlbHksIHRoZQ0KKyAgICBob3N0IG5hbWUgYW5kIG9wdGlvbmFs IHBvcnQgbnVtYmVyIGNhbiBiZSBwYXNzZWQgdG8gdGhlDQorICAgIGNvbnN0 cnVjdG9yLCB0b28uDQorDQorICAgIERvbid0IHRyeSB0byByZW9wZW4gYW4g YWxyZWFkeSBjb25uZWN0ZWQgaW5zdGFuY2UuDQorDQorICAgICIiIg0KKw0K KyAgICBkZWYgb3BlbihzZWxmLCBob3N0LCBwb3J0PTApOg0KKyAgICAgICAg IiIiQ29ubmVjdCB0byBhIGhvc3QuDQorDQorICAgICAgICBUaGUgb3B0aW9u YWwgc2Vjb25kIGFyZ3VtZW50IGlzIHRoZSBwb3J0IG51bWJlciwgd2hpY2gN CisgICAgICAgIGRlZmF1bHRzIHRvIHRoZSBzdGFuZGFyZCB0ZWxuZXQgcG9y dCAoMjMpLg0KKw0KKyAgICAgICAgRG9uJ3QgdHJ5IHRvIHJlb3BlbiBhbiBh bHJlYWR5IGNvbm5lY3RlZCBpbnN0YW5jZS4NCisNCisgICAgICAgICIiIg0K KyAgICAgICAgc2VsZi5lb2YgPSAwDQorICAgICAgICBpZiBub3QgcG9ydDoN CisgICAgICAgICAgICBwb3J0ID0gVEVMTkVUX1BPUlQNCisgICAgICAgIHNl bGYuaG9zdCA9IGhvc3QNCisgICAgICAgIHNlbGYucG9ydCA9IHBvcnQNCisg ICAgICAgIHNlbGYuc29jayA9IHNvY2tldC5zb2NrZXQoc29ja2V0LkFGX0lO RVQsIHNvY2tldC5TT0NLX1NUUkVBTSkNCisgICAgICAgIHNlbGYuc29jay5j b25uZWN0KChzZWxmLmhvc3QsIHNlbGYucG9ydCkpDQorDQorICAgIGRlZiBf X2RlbF9fKHNlbGYpOg0KKyAgICAgICAgIiIiRGVzdHJ1Y3RvciAtLSBjbG9z ZSB0aGUgY29ubmVjdGlvbi4iIiINCisgICAgICAgIHNlbGYuY2xvc2UoKQ0K Kw0KKyAgICBkZWYgY2xvc2Uoc2VsZik6DQorICAgICAgICAiIiJDbG9zZSB0 aGUgY29ubmVjdGlvbi4iIiINCisgICAgICAgIGlmIHNlbGYuc29jazoNCisg ICAgICAgICAgICBzZWxmLnNvY2suY2xvc2UoKQ0KKyAgICAgICAgc2VsZi5z b2NrID0gMA0KKyAgICAgICAgc2VsZi5lb2YgPSAxDQorDQorICAgIGRlZiBn ZXRfc29ja2V0KHNlbGYpOg0KKyAgICAgICAgIiIiUmV0dXJuIHRoZSBzb2Nr ZXQgb2JqZWN0IHVzZWQgaW50ZXJuYWxseS4iIiINCisgICAgICAgIHJldHVy biBzZWxmLnNvY2sNCisNCisgICAgZGVmIGZpbGVubyhzZWxmKToNCisgICAg ICAgICIiIlJldHVybiB0aGUgZmlsZW5vKCkgb2YgdGhlIHNvY2tldCBvYmpl Y3QgdXNlZCBpbnRlcm5hbGx5LiIiIg0KKyAgICAgICAgcmV0dXJuIHNlbGYu c29jay5maWxlbm8oKQ0KKw0KKyAgICBkZWYgd3JpdGUoc2VsZiwgYnVmZmVy KToNCisgICAgICAgICIiIldyaXRlIGEgc3RyaW5nIHRvIHRoZSBzb2NrZXQs IGRvdWJsaW5nIGFueSBJQUMgY2hhcmFjdGVycy4NCisNCisgICAgICAgIENh biBibG9jayBpZiB0aGUgY29ubmVjdGlvbiBpcyBibG9ja2VkLiAgTWF5IHJh aXNlDQorICAgICAgICBzb2NrZXQuZXJyb3IgaWYgdGhlIGNvbm5lY3Rpb24g aXMgY2xvc2VkLg0KKw0KKyAgICAgICAgIiIiDQorICAgICAgICBpZiBJQUMg aW4gYnVmZmVyOg0KKyAgICAgICAgICAgIGJ1ZmZlciA9IHN0cmluZy5yZXBs YWNlKGJ1ZmZlciwgSUFDLCBJQUMrSUFDKQ0KKyAgICAgICAgc2VsZi5tc2co InNlbmQgJXMiLCBgYnVmZmVyYCkNCisgICAgICAgIHNlbGYuc29jay5zZW5k KGJ1ZmZlcikNCisNCisgICAgZGVmIHByb2Nlc3NfcmF3cShzZWxmKToNCisg ICAgICAgICIiIlRyYW5zZmVyIGZyb20gcmF3IHF1ZXVlIHRvIGNvb2tlZCBx dWV1ZS4NCisNCisgICAgICAgIFNldCBzZWxmLmVvZiB3aGVuIGNvbm5lY3Rp b24gaXMgY2xvc2VkLiAgRG9uJ3QgYmxvY2sgdW5sZXNzIGluDQorICAgICAg ICB0aGUgbWlkc3Qgb2YgYW4gSUFDIHNlcXVlbmNlLg0KKw0KKyAgICAgICAg IiIiDQogICAgICAgICBidWYgPSAnJw0KICAgICAgICAgdHJ5Og0KICAgICAg ICAgICAgIHdoaWxlIHNlbGYucmF3cToNCkBAIC0zMzYsMjQgKzQ4OSw2IEBA DQogICAgICAgICAgICAgcGFzcw0KICAgICAgICAgc2VsZi5jb29rZWRxID0g c2VsZi5jb29rZWRxICsgYnVmDQogDQotICAgIGRlZiByYXdxX2dldGNoYXIo c2VsZik6DQotICAgICAgICAiIiJHZXQgbmV4dCBjaGFyIGZyb20gcmF3IHF1 ZXVlLg0KLQ0KLSAgICAgICAgQmxvY2sgaWYgbm8gZGF0YSBpcyBpbW1lZGlh dGVseSBhdmFpbGFibGUuICBSYWlzZSBFT0ZFcnJvcg0KLSAgICAgICAgd2hl biBjb25uZWN0aW9uIGlzIGNsb3NlZC4NCi0NCi0gICAgICAgICIiIg0KLSAg ICAgICAgaWYgbm90IHNlbGYucmF3cToNCi0gICAgICAgICAgICBzZWxmLmZp bGxfcmF3cSgpDQotICAgICAgICAgICAgaWYgc2VsZi5lb2Y6DQotICAgICAg ICAgICAgICAgIHJhaXNlIEVPRkVycm9yDQotICAgICAgICBjID0gc2VsZi5y YXdxW3NlbGYuaXJhd3FdDQotICAgICAgICBzZWxmLmlyYXdxID0gc2VsZi5p cmF3cSArIDENCi0gICAgICAgIGlmIHNlbGYuaXJhd3EgPj0gbGVuKHNlbGYu cmF3cSk6DQotICAgICAgICAgICAgc2VsZi5yYXdxID0gJycNCi0gICAgICAg ICAgICBzZWxmLmlyYXdxID0gMA0KLSAgICAgICAgcmV0dXJuIGMNCi0NCiAg ICAgZGVmIGZpbGxfcmF3cShzZWxmKToNCiAgICAgICAgICIiIkZpbGwgcmF3 IHF1ZXVlIGZyb20gZXhhY3RseSBvbmUgcmVjdigpIHN5c3RlbSBjYWxsLg0K IA0KQEAgLTM3MSw2ICs1MDYsMTAgQEANCiAgICAgICAgIHNlbGYuZW9mID0g KG5vdCBidWYpDQogICAgICAgICBzZWxmLnJhd3EgPSBzZWxmLnJhd3EgKyBi dWYNCiANCisgICAgZGVmIHNlbGVjdChzZWxmLCB0aW1lb3V0KToNCisgICAg ICAgICIiIlRlc3Qgd2hldGhlciBkYXRhIGlzIGF2YWlsYWJsZSBvbiB0aGUg c29ja2V0LiIiIg0KKyAgICAgICAgcmV0dXJuIHNlbGVjdC5zZWxlY3QoW3Nl bGYuZmlsZW5vKCldLCBbXSwgW10sIHRpbWVvdXQpDQorDQogICAgIGRlZiBz b2NrX2F2YWlsKHNlbGYpOg0KICAgICAgICAgIiIiVGVzdCB3aGV0aGVyIGRh dGEgaXMgYXZhaWxhYmxlIG9uIHRoZSBzb2NrZXQuIiIiDQogICAgICAgICBy ZXR1cm4gc2VsZWN0LnNlbGVjdChbc2VsZl0sIFtdLCBbXSwgMCkgPT0gKFtz ZWxmXSwgW10sIFtdKQ0KQEAgLTQxOSw1NiArNTU4LDYgQEANCiAgICAgICAg ICAgICAgICAgc3lzLnN0ZG91dC53cml0ZShkYXRhKQ0KICAgICAgICAgICAg IGVsc2U6DQogICAgICAgICAgICAgICAgIHN5cy5zdGRvdXQuZmx1c2goKQ0K LQ0KLSAgICBkZWYgZXhwZWN0KHNlbGYsIGxpc3QsIHRpbWVvdXQ9Tm9uZSk6 DQotICAgICAgICAiIiJSZWFkIHVudGlsIG9uZSBmcm9tIGEgbGlzdCBvZiBh IHJlZ3VsYXIgZXhwcmVzc2lvbnMgbWF0Y2hlcy4NCi0NCi0gICAgICAgIFRo ZSBmaXJzdCBhcmd1bWVudCBpcyBhIGxpc3Qgb2YgcmVndWxhciBleHByZXNz aW9ucywgZWl0aGVyDQotICAgICAgICBjb21waWxlZCAocmUuUmVnZXhPYmpl Y3QgaW5zdGFuY2VzKSBvciB1bmNvbXBpbGVkIChzdHJpbmdzKS4NCi0gICAg ICAgIFRoZSBvcHRpb25hbCBzZWNvbmQgYXJndW1lbnQgaXMgYSB0aW1lb3V0 LCBpbiBzZWNvbmRzOyBkZWZhdWx0DQotICAgICAgICBpcyBubyB0aW1lb3V0 Lg0KLQ0KLSAgICAgICAgUmV0dXJuIGEgdHVwbGUgb2YgdGhyZWUgaXRlbXM6 IHRoZSBpbmRleCBpbiB0aGUgbGlzdCBvZiB0aGUNCi0gICAgICAgIGZpcnN0 IHJlZ3VsYXIgZXhwcmVzc2lvbiB0aGF0IG1hdGNoZXM7IHRoZSBtYXRjaCBv YmplY3QNCi0gICAgICAgIHJldHVybmVkOyBhbmQgdGhlIHRleHQgcmVhZCB1 cCB0aWxsIGFuZCBpbmNsdWRpbmcgdGhlIG1hdGNoLg0KLQ0KLSAgICAgICAg SWYgRU9GIGlzIHJlYWQgYW5kIG5vIHRleHQgd2FzIHJlYWQsIHJhaXNlIEVP RkVycm9yLg0KLSAgICAgICAgT3RoZXJ3aXNlLCB3aGVuIG5vdGhpbmcgbWF0 Y2hlcywgcmV0dXJuICgtMSwgTm9uZSwgdGV4dCkgd2hlcmUNCi0gICAgICAg IHRleHQgaXMgdGhlIHRleHQgcmVjZWl2ZWQgc28gZmFyIChtYXkgYmUgdGhl IGVtcHR5IHN0cmluZyBpZiBhDQotICAgICAgICB0aW1lb3V0IGhhcHBlbmVk KS4NCi0NCi0gICAgICAgIElmIGEgcmVndWxhciBleHByZXNzaW9uIGVuZHMg d2l0aCBhIGdyZWVkeSBtYXRjaCAoZS5nLiAnLionKQ0KLSAgICAgICAgb3Ig aWYgbW9yZSB0aGFuIG9uZSBleHByZXNzaW9uIGNhbiBtYXRjaCB0aGUgc2Ft ZSBpbnB1dCwgdGhlDQotICAgICAgICByZXN1bHRzIGFyZSB1bmRldGVybWlu aXN0aWMsIGFuZCBtYXkgZGVwZW5kIG9uIHRoZSBJL08gdGltaW5nLg0KLQ0K LSAgICAgICAgIiIiDQotICAgICAgICByZSA9IE5vbmUNCi0gICAgICAgIGxp c3QgPSBsaXN0WzpdDQotICAgICAgICBpbmRpY2VzID0gcmFuZ2UobGVuKGxp c3QpKQ0KLSAgICAgICAgZm9yIGkgaW4gaW5kaWNlczoNCi0gICAgICAgICAg ICBpZiBub3QgaGFzYXR0cihsaXN0W2ldLCAic2VhcmNoIik6DQotICAgICAg ICAgICAgICAgIGlmIG5vdCByZTogaW1wb3J0IHJlDQotICAgICAgICAgICAg ICAgIGxpc3RbaV0gPSByZS5jb21waWxlKGxpc3RbaV0pDQotICAgICAgICB3 aGlsZSAxOg0KLSAgICAgICAgICAgIHNlbGYucHJvY2Vzc19yYXdxKCkNCi0g ICAgICAgICAgICBmb3IgaSBpbiBpbmRpY2VzOg0KLSAgICAgICAgICAgICAg ICBtID0gbGlzdFtpXS5zZWFyY2goc2VsZi5jb29rZWRxKQ0KLSAgICAgICAg ICAgICAgICBpZiBtOg0KLSAgICAgICAgICAgICAgICAgICAgZSA9IG0uZW5k KCkNCi0gICAgICAgICAgICAgICAgICAgIHRleHQgPSBzZWxmLmNvb2tlZHFb OmVdDQotICAgICAgICAgICAgICAgICAgICBzZWxmLmNvb2tlZHEgPSBzZWxm LmNvb2tlZHFbZTpdDQotICAgICAgICAgICAgICAgICAgICByZXR1cm4gKGks IG0sIHRleHQpDQotICAgICAgICAgICAgaWYgc2VsZi5lb2Y6DQotICAgICAg ICAgICAgICAgIGJyZWFrDQotICAgICAgICAgICAgaWYgdGltZW91dCBpcyBu b3QgTm9uZToNCi0gICAgICAgICAgICAgICAgciwgdywgeCA9IHNlbGVjdC5z ZWxlY3QoW3NlbGYuZmlsZW5vKCldLCBbXSwgW10sIHRpbWVvdXQpDQotICAg ICAgICAgICAgICAgIGlmIG5vdCByOg0KLSAgICAgICAgICAgICAgICAgICAg YnJlYWsNCi0gICAgICAgICAgICBzZWxmLmZpbGxfcmF3cSgpDQotICAgICAg ICB0ZXh0ID0gc2VsZi5yZWFkX3ZlcnlfbGF6eSgpDQotICAgICAgICBpZiBu b3QgdGV4dCBhbmQgc2VsZi5lb2Y6DQotICAgICAgICAgICAgcmFpc2UgRU9G RXJyb3INCi0gICAgICAgIHJldHVybiAoLTEsIE5vbmUsIHRleHQpDQogDQog DQogZGVmIHRlc3QoKToNCg== ---888078244-1906648092-983474333=:14207-- From nobody@sourceforge.net Thu Mar 1 22:02:44 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 14:02:44 -0800 Subject: [Patches] [ python-Patches-404826 ] urllib2 enhancements Message-ID: Patches #404826, was updated on 2001-02-28 01:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 Category: library Group: None Status: Closed Priority: 3 Submitted By: Moshe Zadka Assigned to: Fred L. Drake, Jr. Summary: urllib2 enhancements Initial Comment: This are some enhancements and bug fixes to urllib2: * Documentation * Better proxy support, including authentication * HTTPS support ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-01 14:02 Message: Logged In: YES user_id=3066 Done. Working on revising the documentation for consistency; that should be done later tonight. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 00:42 Message: Logged In: YES user_id=11645 Checked in as urllib2.py -- 1.9 liburllib2.tex -- 1.1 Fred, can you add the line \input{liburllib2} wherever you feel appropriate (I'd suggest after \input{liburllib} ;-) and close the patch? Thanks. ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-28 12:00 Message: Logged In: YES user_id=31392 I did a cursory review of the patch and it looks good, particularly the documentation! I would prefer to see this included in the beta. Since there was no documentation before, I don't think there's any problem changing the code. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-02-28 02:31 Message: Logged In: YES user_id=11645 I'm having troubles attaching a file, I've put it up at http://www.lerner.co.il/~moshez/urllib2.py.patch (If anyone manages to attach it, I'll be greateful) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 From nobody@sourceforge.net Thu Mar 1 22:42:09 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 14:42:09 -0800 Subject: [Patches] [ python-Patches-403655 ] configure changes for Solaris Message-ID: Patches #403655, was updated on 2001-02-07 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Scott Griggs Assigned to: Martin v. Löwis Summary: configure changes for Solaris Initial Comment: Configure was setting gcc -shared to build shared libraries on SunOS. Changed it back to gcc -G. The -shared option does not work on Solaris ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:42 Message: Logged In: YES user_id=21627 Since Scott did not provide any rationale or indication of a problem being solved with this patch, I'll reject it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-19 10:24 Message: Okay, I've reverted the patch. Sorry Martin. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-19 09:56 Message: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-18 20:47 Message: Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 From nobody@sourceforge.net Thu Mar 1 22:44:24 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 14:44:24 -0800 Subject: [Patches] [ python-Patches-403655 ] configure changes for Solaris Message-ID: Patches #403655, was updated on 2001-02-07 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Scott Griggs Assigned to: Martin v. Löwis Summary: configure changes for Solaris Initial Comment: Configure was setting gcc -shared to build shared libraries on SunOS. Changed it back to gcc -G. The -shared option does not work on Solaris ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:44 Message: Logged In: YES user_id=21627 Assigned to None. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:42 Message: Logged In: YES user_id=21627 Since Scott did not provide any rationale or indication of a problem being solved with this patch, I'll reject it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-19 10:24 Message: Okay, I've reverted the patch. Sorry Martin. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-19 09:56 Message: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-18 20:47 Message: Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 From nobody@sourceforge.net Thu Mar 1 22:45:44 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 14:45:44 -0800 Subject: [Patches] [ python-Patches-403656 ] configure.in changes for Solaris Message-ID: Patches #403656, was updated on 2001-02-07 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403656&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Scott Griggs Assigned to: Martin v. Löwis Summary: configure.in changes for Solaris Initial Comment: Configure.in was setting gcc -shared to build shared libraries on SunOS. Changed it back to gcc -G. The -shared option does not work on Solaris ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:45 Message: Logged In: YES user_id=21627 This patch does not provide any rationale of what exactly the problem is that is being solved; -shared works fine on Solaris. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-19 10:25 Message: Reverted checkin. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-18 20:49 Message: Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403656&group_id=5470 From nobody@sourceforge.net Fri Mar 2 01:08:28 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 17:08:28 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Guido van Rossum Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Trent Mick Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From nobody@sourceforge.net Fri Mar 2 01:29:53 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 17:29:53 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Guido van Rossum Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From nobody@sourceforge.net Fri Mar 2 02:47:32 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 18:47:32 -0800 Subject: [Patches] [ python-Patches-405228 ] split Telnet class into TelnetBase Message-ID: Patches #405228, was updated on 2001-03-01 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Luke Kenneth Casson Leighton Assigned to: Guido van Rossum Summary: split Telnet class into TelnetBase Initial Comment: I've been asked to make telnet, ssh, bash and rpcclient (http://www.samba-tng.org), http requests and possibly much more all look seamlessly like telnet. That means splitting telnetlib.py's Telnet class down into a base class. I need the write, read_until, expect and friends, but did not want to do a total rewrite / total pain-in-the-neck cut/paste job on telnetlib.py just to fulfil the requirements. I have noticed that someone wrote an scp class, already before: it's available on parnassus. it wraps scp in popen. with this TelnetBase class, doing the same thing will be trivial _and_ you get the exact same look and functionality as if it was a Telnet() instance. well, it makes _me_ happy enough to submit this patch. copyright is hereby assigned to Guido van Rossum. authorship must remain as-is. have fun, luke ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 18:47 Message: Logged In: YES user_id=6380 I'll try to do this after b1 is released. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton Date: 2001-03-01 11:32 Message: Logged In: YES user_id=80200 good grief. what the hell is wrong with sourceforge??? you can't upload files! grrr. diff -u will be sent to patches@python.org. grrr ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 From nobody@sourceforge.net Fri Mar 2 04:31:12 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 20:31:12 -0800 Subject: [Patches] [ python-Patches-405355 ] 2.1b1 Tru64 patch for termios.c Message-ID: Patches #405355, was updated on 2001-03-01 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Mark Favas Assigned to: Nobody/Anonymous Summary: 2.1b1 Tru64 patch for termios.c Initial Comment: Reported as bugid 405350. Modules/termios.c needs some more #ifdef's to compile on Tru64 Unix V4.0F, which doesn't have XTABS, VSWTC or VSWTCH ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 From nobody@sourceforge.net Fri Mar 2 04:35:09 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 20:35:09 -0800 Subject: [Patches] [ python-Patches-405355 ] 2.1b1 Tru64 patch for termios.c Message-ID: Patches #405355, was updated on 2001-03-01 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Mark Favas Assigned to: Nobody/Anonymous Summary: 2.1b1 Tru64 patch for termios.c Initial Comment: Reported as bugid 405350. Modules/termios.c needs some more #ifdef's to compile on Tru64 Unix V4.0F, which doesn't have XTABS, VSWTC or VSWTCH ---------------------------------------------------------------------- Comment By: Mark Favas Date: 2001-03-01 20:35 Message: Logged In: YES user_id=44979 hmm - looks like file didn't get uploaded (hits head) - trying again ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 From nobody@sourceforge.net Fri Mar 2 05:51:47 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 21:51:47 -0800 Subject: [Patches] [ python-Patches-404564 ] tempfile.py: Change order of tmp dirs Message-ID: Patches #404564, was updated on 2001-02-27 05:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Gregor Hoffleit Assigned to: Nobody/Anonymous Summary: tempfile.py: Change order of tmp dirs Initial Comment: [cf. Debian bug#87538, http://bugs.debian.org/87538] Please change the order of the dirs in the attemptdirs list in Lib/tempfile.py. It seems more reasonable according to the FHS (File System Hierarchy Standard), if '/tmp' would precede '/var/tmp': attempdirs = ['/tmp', '/var/tmp', '/usr/tmp', pwd] '/var/tmp' was added recently to the list (Aug 2000, 'Patch by tg@FreeBSD.org to try /var/tmp first. This helps on 4.4BSD-based systems.'). I guess it would make no difference if '/var/tmp' would only tried after '/tmp'. In the words of James Troup : "Well... o /var/tmp/ (at least on Debian) is not cleaned on start-up like /tmp is o /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp o it's not documented o it's unexpected I think a better question might be: what's the advantage of the change? *shrug*" ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 21:51 Message: Logged In: YES user_id=6380 Checking this in now. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 00:47 Message: Logged In: YES user_id=11645 Re: cleanup On Solaris, a tmpwatch script is constantly running and cleans up /tmp from things it thinks are too old, if I remember correctly. In any place, /tmp is often cleaned up on reboot automagically -- when it's a ramdisk (I think AIX does this). It seems more reasonable to put /tmp before /var/tmp given that applications that will want to put files in /var/tmp specifically will do so, while /tmp is not supposed to be used before considering local information, so applications that do that will use tempfile. The discussion has gone way, way, off topic. I say check this in. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 09:16 Message: Logged In: YES user_id=44345 Then the standard is wrong. ;-) I will rephrase: Any system that relies on boot-time cleanup to keep a disk partition from filling up is broken. /tmp is generally on the root partition, the partition that is most dangerous to allow to fill. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit Date: 2001-02-27 08:03 Message: Logged In: YES user_id=5293 Regarding your statement: "If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp." The Linux Standard Base (more specifically: the File System Hierarchy) says this about /var/tmp: 5.12 /var/tmp : Temporary files preserved between system reboots The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. Therefore, if you setup your system to remove files in /var/tmp on reboot, your system will not be compliant with the Linux standard. Moreover, the description for /tmp seems more appropriate for tempfile IMHO: 3.11 /tmp : Temporary files The /tmp directory shall be made available for programs that require temporary files. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Programs shall not assume that any files or directories in /tmp are preserved between invocations of the program. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 07:46 Message: Logged In: YES user_id=44345 Regarding this statement: /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp It is a red herring. /var is often given it's own separate partition precisely because the / partition is often very small. I think /var/tmp should appear before /tmp. If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp. After all, who cares about cleanup at reboot on systems that can remain up for more than a year? What do you think this is - Windows? ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 From nobody@sourceforge.net Fri Mar 2 05:52:21 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 21:52:21 -0800 Subject: [Patches] [ python-Patches-404564 ] tempfile.py: Change order of tmp dirs Message-ID: Patches #404564, was updated on 2001-02-27 05:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Gregor Hoffleit Assigned to: Guido van Rossum Summary: tempfile.py: Change order of tmp dirs Initial Comment: [cf. Debian bug#87538, http://bugs.debian.org/87538] Please change the order of the dirs in the attemptdirs list in Lib/tempfile.py. It seems more reasonable according to the FHS (File System Hierarchy Standard), if '/tmp' would precede '/var/tmp': attempdirs = ['/tmp', '/var/tmp', '/usr/tmp', pwd] '/var/tmp' was added recently to the list (Aug 2000, 'Patch by tg@FreeBSD.org to try /var/tmp first. This helps on 4.4BSD-based systems.'). I guess it would make no difference if '/var/tmp' would only tried after '/tmp'. In the words of James Troup : "Well... o /var/tmp/ (at least on Debian) is not cleaned on start-up like /tmp is o /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp o it's not documented o it's unexpected I think a better question might be: what's the advantage of the change? *shrug*" ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 21:51 Message: Logged In: YES user_id=6380 Checking this in now. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 00:47 Message: Logged In: YES user_id=11645 Re: cleanup On Solaris, a tmpwatch script is constantly running and cleans up /tmp from things it thinks are too old, if I remember correctly. In any place, /tmp is often cleaned up on reboot automagically -- when it's a ramdisk (I think AIX does this). It seems more reasonable to put /tmp before /var/tmp given that applications that will want to put files in /var/tmp specifically will do so, while /tmp is not supposed to be used before considering local information, so applications that do that will use tempfile. The discussion has gone way, way, off topic. I say check this in. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 09:16 Message: Logged In: YES user_id=44345 Then the standard is wrong. ;-) I will rephrase: Any system that relies on boot-time cleanup to keep a disk partition from filling up is broken. /tmp is generally on the root partition, the partition that is most dangerous to allow to fill. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit Date: 2001-02-27 08:03 Message: Logged In: YES user_id=5293 Regarding your statement: "If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp." The Linux Standard Base (more specifically: the File System Hierarchy) says this about /var/tmp: 5.12 /var/tmp : Temporary files preserved between system reboots The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. Therefore, if you setup your system to remove files in /var/tmp on reboot, your system will not be compliant with the Linux standard. Moreover, the description for /tmp seems more appropriate for tempfile IMHO: 3.11 /tmp : Temporary files The /tmp directory shall be made available for programs that require temporary files. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Programs shall not assume that any files or directories in /tmp are preserved between invocations of the program. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 07:46 Message: Logged In: YES user_id=44345 Regarding this statement: /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp It is a red herring. /var is often given it's own separate partition precisely because the / partition is often very small. I think /var/tmp should appear before /tmp. If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp. After all, who cares about cleanup at reboot on systems that can remain up for more than a year? What do you think this is - Windows? ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 From nobody@sourceforge.net Fri Mar 2 05:52:43 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 21:52:43 -0800 Subject: [Patches] [ python-Patches-405016 ] small setup.py patch for VPATH build Message-ID: Patches #405016, was updated on 2001-02-28 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Markus F.X.J. Oberhumer Assigned to: A.M. Kuchling Summary: small setup.py patch for VPATH build Initial Comment: This patch against the current CVS prepends `srcdir' to the `scripts' variable. ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer Date: 2001-02-28 15:13 Message: Logged In: YES user_id=12151 Index: dist/src/setup.py =================================================================== RCS file: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.33 diff -r1.33 setup.py 597a598 > (srcdir,) = sysconfig.get_config_vars('srcdir') 606c607 < scripts = ['Tools/scripts/pydoc'] --- > scripts = [os.path.join(srcdir, 'Tools/scripts/pydoc')] ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer Date: 2001-02-28 15:11 Message: Logged In: YES user_id=12151 (the new sourceforge code is confusing me...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 From nobody@sourceforge.net Fri Mar 2 05:52:42 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 21:52:42 -0800 Subject: [Patches] [ python-Patches-405092 ] Modules/termios.c on Solaris 2.6/SPARC Message-ID: Patches #405092, was updated on 2001-03-01 01:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: The Written Word (china) Assigned to: Fred L. Drake, Jr. Summary: Modules/termios.c on Solaris 2.6/SPARC Initial Comment: Modules/termios.c does not build "out of the box" under Solaris 2.6/SPARC because some values are undefined. The attached patch fixes this. This leaves one error: cc -mr -Qn -xO2 -xtarget=generic -I. -I/opt/build/python-2.1/./Include -IInclude/ -I/usr/local/include -c /opt/build/python-2.1/Modules/termios.c -o build/temp.solaris-2.6-sun4u-2.1/termios.o "/opt/build/python-2.1/Modules/termios.c", line 405: warning: initializer does not fit or is out of range: 0x80000000 The value of CRTSCTS in is: #define CRTSCTS 020000000000 which does not fit in a "long": static struct constant { char *name; long value; } termios_constants[] = { Changing value to 'unsigned long' fixes this but I do not know what repercussions this will have. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 From nobody@sourceforge.net Fri Mar 2 05:53:06 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 21:53:06 -0800 Subject: [Patches] [ python-Patches-405355 ] 2.1b1 Tru64 patch for termios.c Message-ID: Patches #405355, was updated on 2001-03-01 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Mark Favas Assigned to: Fred L. Drake, Jr. Summary: 2.1b1 Tru64 patch for termios.c Initial Comment: Reported as bugid 405350. Modules/termios.c needs some more #ifdef's to compile on Tru64 Unix V4.0F, which doesn't have XTABS, VSWTC or VSWTCH ---------------------------------------------------------------------- Comment By: Mark Favas Date: 2001-03-01 20:35 Message: Logged In: YES user_id=44979 hmm - looks like file didn't get uploaded (hits head) - trying again ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 From nobody@sourceforge.net Fri Mar 2 06:20:40 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 22:20:40 -0800 Subject: [Patches] [ python-Patches-405092 ] Modules/termios.c on Solaris 2.6/SPARC Message-ID: Patches #405092, was updated on 2001-03-01 01:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: The Written Word (china) Assigned to: Fred L. Drake, Jr. Summary: Modules/termios.c on Solaris 2.6/SPARC Initial Comment: Modules/termios.c does not build "out of the box" under Solaris 2.6/SPARC because some values are undefined. The attached patch fixes this. This leaves one error: cc -mr -Qn -xO2 -xtarget=generic -I. -I/opt/build/python-2.1/./Include -IInclude/ -I/usr/local/include -c /opt/build/python-2.1/Modules/termios.c -o build/temp.solaris-2.6-sun4u-2.1/termios.o "/opt/build/python-2.1/Modules/termios.c", line 405: warning: initializer does not fit or is out of range: 0x80000000 The value of CRTSCTS in is: #define CRTSCTS 020000000000 which does not fit in a "long": static struct constant { char *name; long value; } termios_constants[] = { Changing value to 'unsigned long' fixes this but I do not know what repercussions this will have. ---------------------------------------------------------------------- Comment By: The Written Word (china) Date: 2001-03-01 22:20 Message: Logged In: YES user_id=119770 Ok, looks like attaching files does not work. You can find a version here: ftp://ftp.thewrittenword/outgoing/pub/python-2.1-termios.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 From nobody@sourceforge.net Fri Mar 2 06:53:27 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 22:53:27 -0800 Subject: [Patches] [ python-Patches-405355 ] 2.1b1 Tru64 patch for termios.c Message-ID: Patches #405355, was updated on 2001-03-01 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Mark Favas Assigned to: Fred L. Drake, Jr. Summary: 2.1b1 Tru64 patch for termios.c Initial Comment: Reported as bugid 405350. Modules/termios.c needs some more #ifdef's to compile on Tru64 Unix V4.0F, which doesn't have XTABS, VSWTC or VSWTCH ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-01 22:53 Message: Logged In: YES user_id=3066 Fixed in Modules/termios.c revision 2.18. ---------------------------------------------------------------------- Comment By: Mark Favas Date: 2001-03-01 20:35 Message: Logged In: YES user_id=44979 hmm - looks like file didn't get uploaded (hits head) - trying again ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405355&group_id=5470 From nobody@sourceforge.net Fri Mar 2 06:54:09 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 22:54:09 -0800 Subject: [Patches] [ python-Patches-405092 ] Modules/termios.c on Solaris 2.6/SPARC Message-ID: Patches #405092, was updated on 2001-03-01 01:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: The Written Word (china) Assigned to: Fred L. Drake, Jr. Summary: Modules/termios.c on Solaris 2.6/SPARC Initial Comment: Modules/termios.c does not build "out of the box" under Solaris 2.6/SPARC because some values are undefined. The attached patch fixes this. This leaves one error: cc -mr -Qn -xO2 -xtarget=generic -I. -I/opt/build/python-2.1/./Include -IInclude/ -I/usr/local/include -c /opt/build/python-2.1/Modules/termios.c -o build/temp.solaris-2.6-sun4u-2.1/termios.o "/opt/build/python-2.1/Modules/termios.c", line 405: warning: initializer does not fit or is out of range: 0x80000000 The value of CRTSCTS in is: #define CRTSCTS 020000000000 which does not fit in a "long": static struct constant { char *name; long value; } termios_constants[] = { Changing value to 'unsigned long' fixes this but I do not know what repercussions this will have. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-01 22:54 Message: Logged In: YES user_id=3066 Fixed in Modules/termios.c revision 2.18. ---------------------------------------------------------------------- Comment By: The Written Word (china) Date: 2001-03-01 22:20 Message: Logged In: YES user_id=119770 Ok, looks like attaching files does not work. You can find a version here: ftp://ftp.thewrittenword/outgoing/pub/python-2.1-termios.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405092&group_id=5470 From nobody@sourceforge.net Fri Mar 2 06:56:56 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 22:56:56 -0800 Subject: [Patches] [ python-Patches-404162 ] New platform support: RISC OS Message-ID: Patches #404162, was updated on 2001-02-25 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404162&group_id=5470 Category: core (C code) Group: None Status: Closed Priority: 5 Submitted By: Dietmar Schwertberger Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the computers formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains the following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C source and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific C source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 22:56 Message: Logged In: YES user_id=6380 This is checked in now. I expect that there may be glitches -- please check the CVS version or wait until 2.1b1 is released tomorrow. If you have corrections, please submit a new bug report. Note: next time please don't ruin the whitespace before generating the diffs -- I had to manually apply most of the diffs! ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger Date: 2001-02-25 14:48 Message: Logged In: YES user_id=86612 The mentioned archive is available from http://www.schwertberger.de/RISCOSFiles.tar.gz Sorry for having submitted multiple, but my browser and sourceforge seem to dislike each other. Especially uploading seems to be impossible. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404162&group_id=5470 From nobody@sourceforge.net Fri Mar 2 06:58:15 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 22:58:15 -0800 Subject: [Patches] [ python-Patches-405102 ] os.py: fix docstring (make raw) Message-ID: Patches #405102, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Nobody/Anonymous Summary: os.py: fix docstring (make raw) Initial Comment: The docstring for os contains sequences like '\r' that become real control characters; using r""" instead of """ makes the docstring read correctly. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 22:58 Message: Logged In: YES user_id=6380 Ping, please just check this in! You're totally right that this needs fixing. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 03:02 Message: Logged In: YES user_id=11645 As usual, the file was not attached. Ping, can you please put it up somewhere, and give the URL in a comment? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 From nobody@sourceforge.net Fri Mar 2 06:59:31 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 22:59:31 -0800 Subject: [Patches] [ python-Patches-405139 ] Add reset() method to dircache Message-ID: Patches #405139, was updated on 2001-03-01 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Itamar S.T. Assigned to: Nobody/Anonymous Summary: Add reset() method to dircache Initial Comment: The statcache module has a method reset() that resets the cache. The dircache module does not. This simple patch (basically a copy/paste from statcache) adds a reset() method to the dircache module. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 22:59 Message: Logged In: YES user_id=6380 Can you upload the patch or cut and paste it in? SourceForge seems to have lost it (stupid SF bug!). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 From nobody@sourceforge.net Fri Mar 2 07:05:38 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 23:05:38 -0800 Subject: [Patches] [ python-Patches-403642 ] BeOS dislikes import tempfile in _execvpe() Message-ID: Patches #403642, was updated on 2001-02-06 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403642&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Donn Cave Assigned to: Guido van Rossum Summary: BeOS dislikes import tempfile in _execvpe() Initial Comment: UNIX style fork/execve/wait are not fully compatible with thread support on BeOS. For Python, that means neither fork() from import nor import from a fork work reliably. os._execvpe() does the latter, importing tempfile to set up a tantalizing target for hackers. This patch replaces both the tempfile name generation and the exec that uses it, in case we're on BeOS. Need this for setup:distutils:execvp(); symptoms are random crashes and internal BeOS error messages about th name, in case we're on BeOS. It's an issue because setup.py + distutils calls os.execvp(); symptoms are random crashes during setup.py, and internal BeOS error messages about thread IDs. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 23:05 Message: Logged In: YES user_id=6380 Checked in - thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403642&group_id=5470 From nobody@sourceforge.net Fri Mar 2 07:07:37 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 23:07:37 -0800 Subject: [Patches] [ python-Patches-403640 ] incomplete proxy handling in URLLIB Message-ID: Patches #403640, was updated on 2001-02-06 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Tim Peters Summary: incomplete proxy handling in URLLIB Initial Comment: under WinNT, the proxy code takes the proxy values from the registry, but does *not* check for the proxy override settings. The supplied patch does take care of it and works for me. Not very sophisticated, but operational. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 23:07 Message: Logged In: YES user_id=6380 Tim, you seem to be using a proxy, so maybe you can give this a try? Also, it has Win specific code (_winreg usage). If you can't or don't want to, please give it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 From nobody@sourceforge.net Fri Mar 2 07:11:02 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 23:11:02 -0800 Subject: [Patches] [ python-Patches-402357 ] Add support for frameworks and objective-c source. Uesful for both GnuStep and for OSXS/OSX/Darwin. Message-ID: Patches #402357, was updated on 2000-11-11 00:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402357&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Bill Bumgarner Assigned to: Guido van Rossum Summary: Add support for frameworks and objective-c source. Uesful for both GnuStep and for OSXS/OSX/Darwin. Initial Comment: ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 23:11 Message: Logged In: YES user_id=6380 OK, applied. Closing now. (Hey, did SF reopen it automatically as a result of you adding a comment? Neat!) ---------------------------------------------------------------------- Comment By: Bill Bumgarner Date: 2001-03-01 10:52 Message: Logged In: YES user_id=103811 It should use the normal CC referenced compiler as ObjC is integrated directly into gcc and enabled through the use of the -ObjC flag. Index: makesetup =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/makesetup,v retrieving revision 1.34 diff -r1.34 makesetup 207c207 < *.m) obj=`basename $src .m`.o; cc='$(CXX)';; # Obj-C --- > *.m) obj=`basename $src .m`.o; cc='$(CC)';; # Obj-C Thank you. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-01-10 13:46 Message: Applied. Again, somehow the line numbers in your diff were broken! I've changed $(CCC) to $(CXX) since that is now the name of the C++ compiler. If this wasn't what you intended, please get in touch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402357&group_id=5470 From nobody@sourceforge.net Fri Mar 2 07:12:42 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 01 Mar 2001 23:12:42 -0800 Subject: [Patches] [ python-Patches-401702 ] Modify co_filename in frozen programs Message-ID: Patches #401702, was updated on 2000-09-29 04:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401702&group_id=5470 Category: demos and tools Group: None Status: Open Priority: 5 Submitted By: Lawrence Hudson Assigned to: Guido van Rossum Summary: Modify co_filename in frozen programs Initial Comment: ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 23:12 Message: Logged In: YES user_id=6380 Shit. Missed the deadline again. Will try before b2... :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-01-19 14:45 Message: No time to review this before the 2.1a1 release; I'll do this for 2.1a2. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-01-19 07:53 Message: I'm taking this, on the assumption that Mark's too busy and freeze is our shared responsibility. ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-01-18 15:57 Message: (somewhat) randomly reassigned; don't have time to look at this ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2000-10-25 04:19 Message: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ---------------------------------------------------------------------- Comment By: Lawrence Hudson Date: 2000-10-25 01:36 Message: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\python\lib\") 'c:\python\lib' >>> os.path.normpath("c:\python\Lib\") 'c:\python\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2000-10-23 12:33 Message: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2000-09-29 07:28 Message: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ---------------------------------------------------------------------- Comment By: Lawrence Hudson Date: 2000-09-29 04:39 Message: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401702&group_id=5470 From nobody@sourceforge.net Fri Mar 2 11:37:32 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 03:37:32 -0800 Subject: [Patches] [ python-Patches-405410 ] Documentation Non-MSVC-Compilers Message-ID: Patches #405410, was updated on 2001-03-02 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: Documentation Non-MSVC-Compilers Initial Comment: Because someone has to start, here is a first try to explain what to do for using Distutils with Borland C++ and Cygwin/MinGW32. It is certainly not perfect, but I think it contains all important facts, so a more experienced writer can improve the english and style and insert it into the documentation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 From nobody@sourceforge.net Fri Mar 2 11:51:34 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 03:51:34 -0800 Subject: [Patches] [ python-Patches-405139 ] Add reset() method to dircache Message-ID: Patches #405139, was updated on 2001-03-01 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Itamar S.T. Assigned to: Nobody/Anonymous Summary: Add reset() method to dircache Initial Comment: The statcache module has a method reset() that resets the cache. The dircache module does not. This simple patch (basically a copy/paste from statcache) adds a reset() method to the dircache module. ---------------------------------------------------------------------- Comment By: Itamar S.T. Date: 2001-03-02 03:51 Message: Logged In: YES user_id=32065 Wonderful, sourceforge is rejecting all my patches this week. Hope it at least preserves linebreaks in comments... *** dircache.py.orig Thu Mar 1 17:14:51 2001 --- dircache.py Thu Mar 1 17:15:37 2001 *************** *** 8,13 **** --- 8,18 ---- cache = {} + def reset(): + """Reset the cache completely.""" + global cache + cache = {} + def listdir(path): """List directory contents, using cache.""" try: ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 22:59 Message: Logged In: YES user_id=6380 Can you upload the patch or cut and paste it in? SourceForge seems to have lost it (stupid SF bug!). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 From nobody@sourceforge.net Fri Mar 2 12:03:27 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 04:03:27 -0800 Subject: [Patches] [ python-Patches-405410 ] Documentation Non-MSVC-Compilers Message-ID: Patches #405410, was updated on 2001-03-02 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 Category: distutils Group: None Status: Open Priority: 4 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: Documentation Non-MSVC-Compilers Initial Comment: Because someone has to start, here is a first try to explain what to do for using Distutils with Borland C++ and Cygwin/MinGW32. It is certainly not perfect, but I think it contains all important facts, so a more experienced writer can improve the english and style and insert it into the documentation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 From nobody@sourceforge.net Fri Mar 2 12:39:13 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 04:39:13 -0800 Subject: [Patches] [ python-Patches-405410 ] Documentation Non-MSVC-Compilers Message-ID: Patches #405410, was updated on 2001-03-02 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 Category: distutils Group: None Status: Open Priority: 4 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: Documentation Non-MSVC-Compilers Initial Comment: Because someone has to start, here is a first try to explain what to do for using Distutils with Borland C++ and Cygwin/MinGW32. It is certainly not perfect, but I think it contains all important facts, so a more experienced writer can improve the english and style and insert it into the documentation. ---------------------------------------------------------------------- Comment By: Rene Liebscher Date: 2001-03-02 04:39 Message: Logged In: YES user_id=28463 Uploading the file doesn't work!! See htpp://www.htw-dresden.de/~liebschr/doc.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 From nobody@sourceforge.net Fri Mar 2 13:37:56 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 05:37:56 -0800 Subject: [Patches] [ python-Patches-405139 ] Add reset() method to dircache Message-ID: Patches #405139, was updated on 2001-03-01 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Itamar S.T. Assigned to: Guido van Rossum Summary: Add reset() method to dircache Initial Comment: The statcache module has a method reset() that resets the cache. The dircache module does not. This simple patch (basically a copy/paste from statcache) adds a reset() method to the dircache module. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-02 05:37 Message: Logged In: YES user_id=6380 Thanks -- applied now (with an added entry to __all__ for good measure). ---------------------------------------------------------------------- Comment By: Itamar S.T. Date: 2001-03-02 03:51 Message: Logged In: YES user_id=32065 Wonderful, sourceforge is rejecting all my patches this week. Hope it at least preserves linebreaks in comments... *** dircache.py.orig Thu Mar 1 17:14:51 2001 --- dircache.py Thu Mar 1 17:15:37 2001 *************** *** 8,13 **** --- 8,18 ---- cache = {} + def reset(): + """Reset the cache completely.""" + global cache + cache = {} + def listdir(path): """List directory contents, using cache.""" try: ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 22:59 Message: Logged In: YES user_id=6380 Can you upload the patch or cut and paste it in? SourceForge seems to have lost it (stupid SF bug!). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405139&group_id=5470 From nobody@sourceforge.net Fri Mar 2 23:01:29 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 15:01:29 -0800 Subject: [Patches] [ python-Patches-405102 ] os.py: fix docstring (make raw) Message-ID: Patches #405102, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee Assigned to: Ka-Ping Yee Summary: os.py: fix docstring (make raw) Initial Comment: The docstring for os contains sequences like '\r' that become real control characters; using r""" instead of """ makes the docstring read correctly. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-01 22:58 Message: Logged In: YES user_id=6380 Ping, please just check this in! You're totally right that this needs fixing. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-03-01 03:02 Message: Logged In: YES user_id=11645 As usual, the file was not attached. Ping, can you please put it up somewhere, and give the URL in a comment? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 From nobody@sourceforge.net Sat Mar 3 01:12:57 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 17:12:57 -0800 Subject: [Patches] [ python-Patches-405567 ] 2.1b1 termios fix for FreeBSD 4.2 Message-ID: Patches #405567, was updated on 2001-03-02 17:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405567&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Mark Favas Assigned to: Nobody/Anonymous Summary: 2.1b1 termios fix for FreeBSD 4.2 Initial Comment: Another 29 #ifdef's required for FreeBSD (release 4.2-20010225)... Without these, termios fails to link, resulting in a failure in "make test" for test___all__.py, which tries to import termios when testing the "tty" library module. Given the lack of success I had last time trying to upload a patch, I'll list the the symbols that need to be surrounded by "#ifdef XXX... #endif" They are: IUCLC OLCUC OCRNL ONOCR ONLRET OFILL OFDEL NLDLY CRDLY TABDLY BSDLY VTDLY FFDLY NL0 NL1 CR0 CR1 CR2 CR3 TAB0 TAB1 TAB2 TAB3 BS0 BS1 VT0 VT1 FF0 FF1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405567&group_id=5470 From nobody@sourceforge.net Sat Mar 3 01:28:04 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 02 Mar 2001 17:28:04 -0800 Subject: [Patches] [ python-Patches-405567 ] 2.1b1 termios fix for FreeBSD 4.2 Message-ID: Patches #405567, was updated on 2001-03-02 17:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405567&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Mark Favas Assigned to: Nobody/Anonymous Summary: 2.1b1 termios fix for FreeBSD 4.2 Initial Comment: Another 29 #ifdef's required for FreeBSD (release 4.2-20010225)... Without these, termios fails to link, resulting in a failure in "make test" for test___all__.py, which tries to import termios when testing the "tty" library module. Given the lack of success I had last time trying to upload a patch, I'll list the the symbols that need to be surrounded by "#ifdef XXX... #endif" They are: IUCLC OLCUC OCRNL ONOCR ONLRET OFILL OFDEL NLDLY CRDLY TABDLY BSDLY VTDLY FFDLY NL0 NL1 CR0 CR1 CR2 CR3 TAB0 TAB1 TAB2 TAB3 BS0 BS1 VT0 VT1 FF0 FF1 ---------------------------------------------------------------------- Comment By: Mark Favas Date: 2001-03-02 17:28 Message: Logged In: YES user_id=44979 Aaaaaaaaaaaargh! Looks like I'm another for whom file uploads to Sourceforge is broken. If it matters to anyone, I'm using Netscape 4.76 on Unix (Tru64) with SSL. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405567&group_id=5470 From nobody@sourceforge.net Sat Mar 3 18:09:11 2001 From: nobody@sourceforge.net (nobody) Date: Sat, 03 Mar 2001 10:09:11 -0800 Subject: [Patches] [ python-Patches-405567 ] 2.1b1 termios fix for FreeBSD 4.2 Message-ID: Patches #405567, was updated on 2001-03-02 17:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405567&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Mark Favas Assigned to: Fred L. Drake, Jr. Summary: 2.1b1 termios fix for FreeBSD 4.2 Initial Comment: Another 29 #ifdef's required for FreeBSD (release 4.2-20010225)... Without these, termios fails to link, resulting in a failure in "make test" for test___all__.py, which tries to import termios when testing the "tty" library module. Given the lack of success I had last time trying to upload a patch, I'll list the the symbols that need to be surrounded by "#ifdef XXX... #endif" They are: IUCLC OLCUC OCRNL ONOCR ONLRET OFILL OFDEL NLDLY CRDLY TABDLY BSDLY VTDLY FFDLY NL0 NL1 CR0 CR1 CR2 CR3 TAB0 TAB1 TAB2 TAB3 BS0 BS1 VT0 VT1 FF0 FF1 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-03 10:09 Message: Logged In: YES user_id=3066 Fixed in Modules/termios.c revision 2.19. ---------------------------------------------------------------------- Comment By: Mark Favas Date: 2001-03-02 17:28 Message: Logged In: YES user_id=44979 Aaaaaaaaaaaargh! Looks like I'm another for whom file uploads to Sourceforge is broken. If it matters to anyone, I'm using Netscape 4.76 on Unix (Tru64) with SSL. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405567&group_id=5470 From nobody@sourceforge.net Sat Mar 3 19:19:28 2001 From: nobody@sourceforge.net (nobody) Date: Sat, 03 Mar 2001 11:19:28 -0800 Subject: [Patches] [ python-Patches-405410 ] Documentation Non-MSVC-Compilers Message-ID: Patches #405410, was updated on 2001-03-02 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 Category: distutils Group: None Status: Closed Priority: 4 Submitted By: Rene Liebscher Assigned to: Fred L. Drake, Jr. Summary: Documentation Non-MSVC-Compilers Initial Comment: Because someone has to start, here is a first try to explain what to do for using Distutils with Borland C++ and Cygwin/MinGW32. It is certainly not perfect, but I think it contains all important facts, so a more experienced writer can improve the english and style and insert it into the documentation. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-03 11:19 Message: Logged In: YES user_id=3066 Checked in with minor changes as Doc/inst/inst.tex revision 1.30. Thanks! ---------------------------------------------------------------------- Comment By: Rene Liebscher Date: 2001-03-02 04:39 Message: Logged In: YES user_id=28463 Uploading the file doesn't work!! See htpp://www.htw-dresden.de/~liebschr/doc.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405410&group_id=5470 From nobody@sourceforge.net Sun Mar 4 05:14:35 2001 From: nobody@sourceforge.net (nobody) Date: Sat, 03 Mar 2001 21:14:35 -0800 Subject: [Patches] [ python-Patches-405792 ] Run configure instead of config.status Message-ID: Patches #405792, was updated on 2001-03-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer Assigned to: Guido van Rossum Summary: Run configure instead of config.status Initial Comment: The config.status script does not check configure's exit status. This causes an infinite loop if configure is newer than config.status and configure fails for some reason. One way to test this is to first run configure and then add an "exit 1" line at the top of configure. Running make will cause an infinite loop. I think its best to avoid using config.status all together. Its easy to save the configure arguments. Assigned to Guido since it looks like he originally add the WITH variable. Will anyone care if we get rid of it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 From nobody@sourceforge.net Sun Mar 4 16:57:41 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 08:57:41 -0800 Subject: [Patches] [ python-Patches-405845 ] Fix for #405427: raise BadStatusLine Message-ID: Patches #405845, was updated on 2001-03-04 08:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405845&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Jeremy Hylton Summary: Fix for #405427: raise BadStatusLine Initial Comment: If the status code is not well-formatted, this patch raises a BadStatusLine exception ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405845&group_id=5470 From nobody@sourceforge.net Sun Mar 4 16:59:18 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 08:59:18 -0800 Subject: [Patches] [ python-Patches-405845 ] Fix for #405427: raise BadStatusLine Message-ID: Patches #405845, was updated on 2001-03-04 08:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405845&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Jeremy Hylton Summary: Fix for #405427: raise BadStatusLine Initial Comment: If the status code is not well-formatted, this patch raises a BadStatusLine exception ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-04 08:59 Message: Logged In: YES user_id=21627 Since patch upload still does not work, I attach it inline Index: httplib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/httplib.py,v retrieving revision 1.33 diff -u -r1.33 httplib.py --- httplib.py 2001/02/01 23:35:20 1.33 +++ httplib.py 2001/03/04 16:52:34 @@ -126,7 +126,15 @@ self.close() raise BadStatusLine(line) - self.status = status = int(status) + # The status code is a three-digit number + if len(status) != 3: + raise BadStatusLine(line) + try: + self.status = status = int(status) + if status < 100: + raise BadStatusLine(line) + except ValueError: + raise BadStatusLine(line) self.reason = reason.strip() if version == 'HTTP/1.0': --- /dev/null Fri Dec 22 00:32:13 2000 +++ test/test_httplib.py Sun Mar 4 17:53:00 2001 @@ -0,0 +1,31 @@ +from test.test_support import verify,verbose +import httplib +import StringIO + +class FakeSocket: + def __init__(self, text): + self.text = text + + def makefile(self, mode, bufsize=None): + if mode != 'r' and mode != 'rb': + raise UnimplementedFileMode() + return StringIO.StringIO(self.text) + +# Test HTTP status lines + +body = "HTTP/1.1 200 Ok\r\n\r\nText" +sock = FakeSocket(body) +resp = httplib.HTTPResponse(sock,1) +resp.begin() +print resp.read() +resp.close() + +body = "HTTP/1.1 400.100 Not Ok\r\n\r\nText" +sock = FakeSocket(body) +resp = httplib.HTTPResponse(sock,1) +try: + resp.begin() +except httplib.BadStatusLine: + print "PASS" +else: + print "FAIL" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405845&group_id=5470 From nobody@sourceforge.net Sun Mar 4 17:36:56 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 09:36:56 -0800 Subject: [Patches] [ python-Patches-405851 ] Allow jython to complete test_strftime Message-ID: Patches #405851, was updated on 2001-03-04 09:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Finn Bock Assigned to: Nobody/Anonymous Summary: Allow jython to complete test_strftime Initial Comment: Java always eun with a national locale. As a result the default strings from the "time" module is national. This path will assign a US locale and allow a successful test even when running with a non-us computer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 From nobody@sourceforge.net Sun Mar 4 17:45:41 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 09:45:41 -0800 Subject: [Patches] [ python-Patches-405853 ] Allow jython to use site.py Message-ID: Patches #405853, was updated on 2001-03-04 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Finn Bock Assigned to: Nobody/Anonymous Summary: Allow jython to use site.py Initial Comment: Change 1: Not all 'modules' in sys.modules have a sensible __file__ attribute. Some of our java package can have the __file__ attribute set to None. Change 2: In jython we have the jython license file in and the CPython license file in /Lib. By reversing the search sequence jython will find and show the jython license file before the CPython file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 From nobody@sourceforge.net Sun Mar 4 17:48:13 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 09:48:13 -0800 Subject: [Patches] [ python-Patches-405853 ] Allow jython to use site.py Message-ID: Patches #405853, was updated on 2001-03-04 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Finn Bock Assigned to: Nobody/Anonymous Summary: Allow jython to use site.py Initial Comment: Change 1: Not all 'modules' in sys.modules have a sensible __file__ attribute. Some of our java package can have the __file__ attribute set to None. Change 2: In jython we have the jython license file in and the CPython license file in /Lib. By reversing the search sequence jython will find and show the jython license file before the CPython file. ---------------------------------------------------------------------- Comment By: Finn Bock Date: 2001-03-04 09:48 Message: Logged In: YES user_id=4201 Forgot to mark the upload checkbox. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 From nobody@sourceforge.net Sun Mar 4 23:57:54 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 15:57:54 -0800 Subject: [Patches] [ python-Patches-403655 ] configure changes for Solaris Message-ID: Patches #403655, was updated on 2001-02-07 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Scott Griggs Assigned to: Martin v. Löwis Summary: configure changes for Solaris Initial Comment: Configure was setting gcc -shared to build shared libraries on SunOS. Changed it back to gcc -G. The -shared option does not work on Solaris ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 15:57 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:44 Message: Logged In: YES user_id=21627 Assigned to None. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:42 Message: Logged In: YES user_id=21627 Since Scott did not provide any rationale or indication of a problem being solved with this patch, I'll reject it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-19 10:24 Message: Okay, I've reverted the patch. Sorry Martin. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-19 09:56 Message: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-18 20:47 Message: Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 From nobody@sourceforge.net Sun Mar 4 23:59:10 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 15:59:10 -0800 Subject: [Patches] [ python-Patches-403655 ] configure changes for Solaris Message-ID: Patches #403655, was updated on 2001-02-07 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Scott Griggs Assigned to: Martin v. Löwis Summary: configure changes for Solaris Initial Comment: Configure was setting gcc -shared to build shared libraries on SunOS. Changed it back to gcc -G. The -shared option does not work on Solaris ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 15:59 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 15:57 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:44 Message: Logged In: YES user_id=21627 Assigned to None. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:42 Message: Logged In: YES user_id=21627 Since Scott did not provide any rationale or indication of a problem being solved with this patch, I'll reject it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-19 10:24 Message: Okay, I've reverted the patch. Sorry Martin. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-19 09:56 Message: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-18 20:47 Message: Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 From nobody@sourceforge.net Mon Mar 5 00:00:36 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 16:00:36 -0800 Subject: [Patches] [ python-Patches-403655 ] configure changes for Solaris Message-ID: Patches #403655, was updated on 2001-02-07 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Scott Griggs Assigned to: Martin v. Löwis Summary: configure changes for Solaris Initial Comment: Configure was setting gcc -shared to build shared libraries on SunOS. Changed it back to gcc -G. The -shared option does not work on Solaris ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 16:00 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 15:59 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 15:57 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:44 Message: Logged In: YES user_id=21627 Assigned to None. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:42 Message: Logged In: YES user_id=21627 Since Scott did not provide any rationale or indication of a problem being solved with this patch, I'll reject it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-19 10:24 Message: Okay, I've reverted the patch. Sorry Martin. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-19 09:56 Message: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-18 20:47 Message: Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 From nobody@sourceforge.net Mon Mar 5 04:39:24 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 20:39:24 -0800 Subject: [Patches] [ python-Patches-405931 ] Patches for SCO UnixWae 7.1.x port Message-ID: Patches #405931, was updated on 2001-03-04 20:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie Assigned to: Nobody/Anonymous Summary: Patches for SCO UnixWae 7.1.x port Initial Comment: The attached file contains patches and files needed to allow Python-2.1 to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1 executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b1-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: dfb9ec40ab4b88b70abad9f1966fa3e0 Billy G. Allie ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 From nobody@sourceforge.net Mon Mar 5 07:20:01 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 04 Mar 2001 23:20:01 -0800 Subject: [Patches] [ python-Patches-405952 ] cmd.py uses raw_input(); eats SIGCLD Message-ID: Patches #405952, was updated on 2001-03-04 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Anthony Baxter Assigned to: Nobody/Anonymous Summary: cmd.py uses raw_input(); eats SIGCLD Initial Comment: I discovered a rather nasty side effect of the standard cmd.py library today. If it's sitting inside raw_input(), any SIGCLDs that get sent to your application get silently eaten and ignored. I'm assuming that this is something that readline is thoughtfully doing for me. This patch adds an instance attr that allows the user to select to not use raw_input(), but instead use sys.stdin.readline() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 From nobody@sourceforge.net Mon Mar 5 10:07:39 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 05 Mar 2001 02:07:39 -0800 Subject: [Patches] [ python-Patches-403655 ] configure changes for Solaris Message-ID: Patches #403655, was updated on 2001-02-07 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Scott Griggs Assigned to: Martin v. Löwis Summary: configure changes for Solaris Initial Comment: Configure was setting gcc -shared to build shared libraries on SunOS. Changed it back to gcc -G. The -shared option does not work on Solaris ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-05 02:07 Message: Logged In: YES user_id=21627 When you get such errors for libz, then obviously your libz installation is broken, in the sense that it is not capable of being linked into a shared library. There is a number of solutions to the problem: a) rebuild libz with the -fPIC/-KPIC option, b) link the zlib module statically into Python, by activating the relevant line in Modules/Setup c) pass the -mimpure-text module to the zlib compilation, either by putting it into Modules/Setup, or by setting CCFLAGS before invoking autoconf. Since using -G alone will produce incorrect libraries, and since using impure text results in a performance loss, it is clearly not something that the standard distribution should use; local administrators will need to configure Python properly. ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 16:00 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 15:59 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Jeffrey Chang Date: 2001-03-04 15:57 Message: Logged In: YES user_id=12576 I'm sorry to see this patch backed out, since it solves my problem. I'm using SunOS 5.6 with gcc 2.8.1. When gcc -shared tries to link against .a files, I get a slew of errors such as: [...] 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections WARNING: building of extension "zlib" failed: command 'gcc' failed with exit status 1 These messages, and the error, goes away when using gcc -G. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:44 Message: Logged In: YES user_id=21627 Assigned to None. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-01 14:42 Message: Logged In: YES user_id=21627 Since Scott did not provide any rationale or indication of a problem being solved with this patch, I'll reject it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-19 10:24 Message: Okay, I've reverted the patch. Sorry Martin. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-19 09:56 Message: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-18 20:47 Message: Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470 From nobody@sourceforge.net Mon Mar 5 18:31:14 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 05 Mar 2001 10:31:14 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for #406049 Message-ID: Patches #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Michael Hudson Assigned to: Nobody/Anonymous Summary: fix for #406049 Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From nobody@sourceforge.net Mon Mar 5 18:55:03 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 05 Mar 2001 10:55:03 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for #406049 Message-ID: Patches #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Michael Hudson Assigned to: Nobody/Anonymous Summary: fix for #406049 Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- Comment By: Michael Hudson Date: 2001-03-05 10:55 Message: Logged In: YES user_id=6656 trying again. passes make test now. now the numbers in the names of the list comp temporaries increase throughout the file being compiled. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From nobody@sourceforge.net Mon Mar 5 18:56:41 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 05 Mar 2001 10:56:41 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for #406049 Message-ID: Patches #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Michael Hudson Assigned to: Nobody/Anonymous Summary: fix for #406049 Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- Comment By: Michael Hudson Date: 2001-03-05 10:56 Message: Logged In: YES user_id=6656 upload the right file... ---------------------------------------------------------------------- Comment By: Michael Hudson Date: 2001-03-05 10:55 Message: Logged In: YES user_id=6656 trying again. passes make test now. now the numbers in the names of the list comp temporaries increase throughout the file being compiled. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From nobody@sourceforge.net Mon Mar 5 19:41:13 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 05 Mar 2001 11:41:13 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for #406049 Message-ID: Patches #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Michael Hudson Assigned to: Nobody/Anonymous Summary: fix for #406049 Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- Comment By: Michael Hudson Date: 2001-03-05 10:56 Message: Logged In: YES user_id=6656 upload the right file... ---------------------------------------------------------------------- Comment By: Michael Hudson Date: 2001-03-05 10:55 Message: Logged In: YES user_id=6656 trying again. passes make test now. now the numbers in the names of the list comp temporaries increase throughout the file being compiled. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From nobody@sourceforge.net Tue Mar 6 09:26:17 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 01:26:17 -0800 Subject: [Patches] [ python-Patches-406248 ] Enable Weak References to Functions Message-ID: Patches #406248, was updated on 2001-03-06 01:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406248&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Phil Thompson Assigned to: Nobody/Anonymous Summary: Enable Weak References to Functions Initial Comment: The patch enables weak references for functions, mainly useful for lambda functions. Without this patch it is possible for a PyQt programmer to write scripts that will seg fault the interpreter. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406248&group_id=5470 From nobody@sourceforge.net Tue Mar 6 12:47:10 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 04:47:10 -0800 Subject: [Patches] [ python-Patches-406270 ] termios.c: doesn't compile on FreeBSD Message-ID: Patches #406270, was updated on 2001-03-06 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406270&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: termios.c: doesn't compile on FreeBSD Initial Comment: blafasel ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406270&group_id=5470 From nobody@sourceforge.net Tue Mar 6 12:49:05 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 04:49:05 -0800 Subject: [Patches] [ python-Patches-406271 ] use INSTALL_SCRIPT to install scripts Message-ID: Patches #406271, was updated on 2001-03-06 04:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406271&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: use INSTALL_SCRIPT to install scripts Initial Comment: see diff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406271&group_id=5470 From nobody@sourceforge.net Tue Mar 6 12:51:20 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 04:51:20 -0800 Subject: [Patches] [ python-Patches-406272 ] use INSTALL_SCRIPT to install scripts Message-ID: Patches #406272, was updated on 2001-03-06 04:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406272&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: use INSTALL_SCRIPT to install scripts Initial Comment: see diff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406272&group_id=5470 From nobody@sourceforge.net Tue Mar 6 13:28:48 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 05:28:48 -0800 Subject: [Patches] [ python-Patches-406287 ] last try: INSTALL_SCRIPT Message-ID: Patches #406287, was updated on 2001-03-06 05:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406287&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: last try: INSTALL_SCRIPT Initial Comment: see diff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406287&group_id=5470 From nobody@sourceforge.net Tue Mar 6 13:30:35 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 05:30:35 -0800 Subject: [Patches] [ python-Patches-406272 ] use INSTALL_SCRIPT to install scripts Message-ID: Patches #406272, was updated on 2001-03-06 04:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406272&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: use INSTALL_SCRIPT to install scripts Initial Comment: see diff ---------------------------------------------------------------------- Comment By: Nobody/Anonymous Date: 2001-03-06 05:30 Message: Logged In: NO Please delete this PR. The patch is in #406287. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406272&group_id=5470 From nobody@sourceforge.net Tue Mar 6 13:31:51 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 05:31:51 -0800 Subject: [Patches] [ python-Patches-406271 ] use INSTALL_SCRIPT to install scripts Message-ID: Patches #406271, was updated on 2001-03-06 04:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406271&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: use INSTALL_SCRIPT to install scripts Initial Comment: see diff ---------------------------------------------------------------------- Comment By: Nobody/Anonymous Date: 2001-03-06 05:31 Message: Logged In: NO Please delete this PR. The patch is in #406287. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406271&group_id=5470 From nobody@sourceforge.net Tue Mar 6 18:23:22 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 10:23:22 -0800 Subject: [Patches] [ python-Patches-406272 ] use INSTALL_SCRIPT to install scripts Message-ID: Patches #406272, was updated on 2001-03-06 04:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406272&group_id=5470 Category: Build Group: None Status: Deleted Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: use INSTALL_SCRIPT to install scripts Initial Comment: see diff ---------------------------------------------------------------------- Comment By: Nobody/Anonymous Date: 2001-03-06 05:30 Message: Logged In: NO Please delete this PR. The patch is in #406287. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406272&group_id=5470 From nobody@sourceforge.net Tue Mar 6 18:23:53 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 10:23:53 -0800 Subject: [Patches] [ python-Patches-406271 ] use INSTALL_SCRIPT to install scripts Message-ID: Patches #406271, was updated on 2001-03-06 04:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406271&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: use INSTALL_SCRIPT to install scripts Initial Comment: see diff ---------------------------------------------------------------------- Comment By: Nobody/Anonymous Date: 2001-03-06 05:31 Message: Logged In: NO Please delete this PR. The patch is in #406287. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406271&group_id=5470 From nobody@sourceforge.net Tue Mar 6 18:27:42 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 10:27:42 -0800 Subject: [Patches] [ python-Patches-406270 ] termios.c: doesn't compile on FreeBSD Message-ID: Patches #406270, was updated on 2001-03-06 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406270&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: termios.c: doesn't compile on FreeBSD Initial Comment: blafasel ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-03-06 10:27 Message: Logged In: YES user_id=34209 Something similar to this fix has already been checked in, late last week, by Fred. (Probably after the beta release.) If the current CVS tree still doesn't work for you, please resubmit a patch relative to it, not the beta release or an old CVS tree. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406270&group_id=5470 From nobody@sourceforge.net Tue Mar 6 18:45:15 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 06 Mar 2001 10:45:15 -0800 Subject: [Patches] [ python-Patches-405931 ] Patches for SCO UnixWare 7.1.x port Message-ID: Patches #405931, was updated on 2001-03-04 20:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie Assigned to: Nobody/Anonymous Summary: Patches for SCO UnixWare 7.1.x port Initial Comment: The attached file contains patches and files needed to allow Python-2.1 to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1 executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b1-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: dfb9ec40ab4b88b70abad9f1966fa3e0 Billy G. Allie ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 From nobody@usw-sf-web1.sourceforge.net Thu Mar 8 18:03:01 2001 From: nobody@usw-sf-web1.sourceforge.net (nobody) Date: Thu, 08 Mar 2001 10:03:01 -0800 Subject: [Patches] [ python-Patches-407093 ] urllib2 correction of typos Message-ID: Patches #407093, was updated on 2001-03-08 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407093&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Eduardo Fernandez Corrales Assigned to: Nobody/Anonymous Summary: urllib2 correction of typos Initial Comment: Bug #406683 "typos in urllib2" includes a patch. I have modified it so that Basic HTTP Authentication works now. (At least with my Squid proxy) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407093&group_id=5470 From nobody@sourceforge.net Thu Mar 8 20:29:17 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 08 Mar 2001 12:29:17 -0800 Subject: [Patches] [ python-Patches-407148 ] 'D' format option for Py_BuildValue Message-ID: Patches #407148, was updated on 2001-03-08 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407148&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Walter Dörwald Assigned to: Nobody/Anonymous Summary: 'D' format option for Py_BuildValue Initial Comment: This patch add the 'D' format specifier to Py_BuildValue for constructing complex Python numbers out of a Py_complex C structure. A patch to the documentation is included. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407148&group_id=5470 From nobody@sourceforge.net Thu Mar 8 20:29:32 2001 From: nobody@sourceforge.net (nobody) Date: Thu, 08 Mar 2001 12:29:32 -0800 Subject: [Patches] [ python-Patches-407149 ] 'D' format option for Py_BuildValue Message-ID: Patches #407149, was updated on 2001-03-08 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407149&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Walter Dörwald Assigned to: Nobody/Anonymous Summary: 'D' format option for Py_BuildValue Initial Comment: This patch add the 'D' format specifier to Py_BuildValue for constructing complex Python numbers out of a Py_complex C structure. A patch to the documentation is included. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407149&group_id=5470 From nobody@sourceforge.net Sat Mar 10 01:31:20 2001 From: nobody@sourceforge.net (nobody) Date: Fri, 09 Mar 2001 17:31:20 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Amos Latteier Assigned to: Nobody/Anonymous Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From www.tooltoad.com" www.tooltoad.com www.tooltoad.com www.tooltoad.com HELLO , Please visit us at the GRAND OPENING of www.tooltoad.com Come and see our ROCK BOTTOM pennies on the dollar pricing . We sell electronics , housewares , security items , tools , and much more . THANK YOU The management From nobody@sourceforge.net Sat Mar 10 19:45:30 2001 From: nobody@sourceforge.net (nobody) Date: Sat, 10 Mar 2001 11:45:30 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Amos Latteier Assigned to: A.M. Kuchling Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From nobody@sourceforge.net Sat Mar 10 19:51:23 2001 From: nobody@sourceforge.net (nobody) Date: Sat, 10 Mar 2001 11:51:23 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Amos Latteier Assigned to: A.M. Kuchling Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-03-10 11:51 Message: Logged In: YES user_id=11375 You seem to have run into the SourceForge file upload bug, because there isn't a patch attached. You may want to try again, or put it on the Web somewhere. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From nobody@sourceforge.net Sat Mar 10 21:58:07 2001 From: nobody@sourceforge.net (nobody) Date: Sat, 10 Mar 2001 13:58:07 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Amos Latteier Assigned to: A.M. Kuchling Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- Comment By: Amos Latteier Date: 2001-03-10 13:58 Message: Logged In: YES user_id=157880 I am attempting to upload the patch again. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-03-10 11:51 Message: Logged In: YES user_id=11375 You seem to have run into the SourceForge file upload bug, because there isn't a patch attached. You may want to try again, or put it on the Web somewhere. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From nobody@sourceforge.net Sat Mar 10 22:25:04 2001 From: nobody@sourceforge.net (nobody) Date: Sat, 10 Mar 2001 14:25:04 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Amos Latteier Assigned to: A.M. Kuchling Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-03-10 14:25 Message: Logged In: YES user_id=11375 That worked. The patch looks reasonable. There's little point in checking it in at this point, though, until we settle on the metadata fields and decide the XML-vs-other-formats question. ---------------------------------------------------------------------- Comment By: Amos Latteier Date: 2001-03-10 13:58 Message: Logged In: YES user_id=157880 I am attempting to upload the patch again. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-03-10 11:51 Message: Logged In: YES user_id=11375 You seem to have run into the SourceForge file upload bug, because there isn't a patch attached. You may want to try again, or put it on the Web somewhere. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From nobody@sourceforge.net Sun Mar 11 21:15:23 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 11 Mar 2001 13:15:23 -0800 Subject: [Patches] [ python-Patches-407758 ] timemodule patches for Cygwin Message-ID: Patches #407758, was updated on 2001-03-11 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407758&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Norman Vine Assigned to: Nobody/Anonymous Summary: timemodule patches for Cygwin Initial Comment: Simple patch to fix timezone support on Cygwin ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407758&group_id=5470 From nobody@sourceforge.net Sun Mar 11 21:37:56 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 11 Mar 2001 13:37:56 -0800 Subject: [Patches] [ python-Patches-407764 ] allow whitespace lines for doctest tests Message-ID: Patches #407764, was updated on 2001-03-11 13:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Trent Mick Assigned to: Tim Peters Summary: allow whitespace lines for doctest tests Initial Comment: Currently doctest.py does not allow individual tests to have all-whitespace output lines. This patch proposes a fix for this. With this patch a leading '.' on a doctest output line, if and only if the tests are indented, will signal that following whitespace *is* the expected output. For example, currently this cannot be doctest'ed """ >>> print "\nhello\n" hello >>> """ But with this patch *this* can be: # file test_doctest.py """ >>> print "\nhello\n" . hello . >>> """ def _test(): import doctest, test_doctest return doctest.testmod(test_doctest) if __name__ == "__main__": _test() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 From nobody@sourceforge.net Sun Mar 11 21:40:12 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 11 Mar 2001 13:40:12 -0800 Subject: [Patches] [ python-Patches-407764 ] allow whitespace lines for doctest tests Message-ID: Patches #407764, was updated on 2001-03-11 13:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Trent Mick Assigned to: Tim Peters Summary: allow whitespace lines for doctest tests Initial Comment: Currently doctest.py does not allow individual tests to have all-whitespace output lines. This patch proposes a fix for this. With this patch a leading '.' on a doctest output line, if and only if the tests are indented, will signal that following whitespace *is* the expected output. For example, currently this cannot be doctest'ed """ >>> print "\nhello\n" hello >>> """ But with this patch *this* can be: # file test_doctest.py """ >>> print "\nhello\n" . hello . >>> """ def _test(): import doctest, test_doctest return doctest.testmod(test_doctest) if __name__ == "__main__": _test() ---------------------------------------------------------------------- Comment By: Trent Mick Date: 2001-03-11 13:40 Message: Logged In: YES user_id=34892 Grrr, the code I put in the comment is supposed to be indented of course. I will attach the test_doctest.py to clarify. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 From nobody@sourceforge.net Mon Mar 12 00:19:13 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 11 Mar 2001 16:19:13 -0800 Subject: [Patches] [ python-Patches-407148 ] 'D' format option for Py_BuildValue Message-ID: Patches #407148, was updated on 2001-03-08 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407148&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Walter Dörwald Assigned to: Fred L. Drake, Jr. Summary: 'D' format option for Py_BuildValue Initial Comment: This patch add the 'D' format specifier to Py_BuildValue for constructing complex Python numbers out of a Py_complex C structure. A patch to the documentation is included. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-11 16:19 Message: Logged In: YES user_id=6380 Looks good to me. Fred, can you do the honors? (If not, assign to me please!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407148&group_id=5470 From nobody@sourceforge.net Mon Mar 12 00:22:20 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 11 Mar 2001 16:22:20 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for #406049 Message-ID: Patches #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Michael Hudson Assigned to: Jeremy Hylton Summary: fix for #406049 Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-11 16:22 Message: Logged In: YES user_id=6380 Assigned to jeremy. I've deleted the bogus files. ---------------------------------------------------------------------- Comment By: Michael Hudson Date: 2001-03-05 10:56 Message: Logged In: YES user_id=6656 upload the right file... ---------------------------------------------------------------------- Comment By: Michael Hudson Date: 2001-03-05 10:55 Message: Logged In: YES user_id=6656 trying again. passes make test now. now the numbers in the names of the list comp temporaries increase throughout the file being compiled. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From chris@collegewafer.com Mon Mar 12 04:29:52 2001 From: chris@collegewafer.com (Chris Baker) Date: Sun, 11 Mar 2001 23:29:52 -0500 Subject: [Patches] We have your Wafers Ge, InP, GaAs, SOI, ZnO, ZnS, ZnSe, Sapphire & More! Message-ID: Visit http://www.collegewafer.com or call 800-713-9375, Fax 888-832-0340 or email chris@collegewafer.com Just arrived! New stocks of 2"6" GaAs, GaSb, Cap Germanium, InP, InAs, InSb, Sapphire and more! They're ready to ship! Get your FREE quote today! We also have: Cleaning, Lapping, Etching, Edge round, graphic printouts (2D & 3D), Certificate of Conformance, Certificate of Analysis, Polishing, Reclaim Services, Laser-cutting and Oxide Services Ask about In-House Oxide Services: Thermally grown oxide for 2"-8" wafers ranging in thickness from 500-100,000 Angstroms. To Remove yourself, please click the link http://www.collegewafer.com/contact_us/Remove/remove.html mtlll From nobody@sourceforge.net Mon Mar 12 18:18:14 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 12 Mar 2001 10:18:14 -0800 Subject: [Patches] [ python-Patches-407965 ] Improve Level 2 conformance of minidom Message-ID: Patches #407965, was updated on 2001-03-12 10:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 Category: XML Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Fred L. Drake, Jr. Summary: Improve Level 2 conformance of minidom Initial Comment: This patch fixes a number of minidom bugs that occurred when trying to port 4XSLT to it: - addition of a DocumentFragment implementation and createDocumentFragment method - proper setting of ownerDocument for all nodes - setting of namespaceURI to None in Element as a class attribute - addition of setAttributeNodeNS and removeAttributeNodeNS as aliases for setAttributeNode and removeAttributeNode - support for inheriting from DOMImplementation to extend it with additional features (to override the Document class) in pulldom: - support for nodes (comment and PI) that occur before the document element; that became necessary as pulldom now delays creation of the document until it has the document element. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 From nobody@sourceforge.net Mon Mar 12 18:30:57 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 12 Mar 2001 10:30:57 -0800 Subject: [Patches] [ python-Patches-407965 ] Improve Level 2 conformance of minidom Message-ID: Patches #407965, was updated on 2001-03-12 10:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 Category: XML Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Fred L. Drake, Jr. Summary: Improve Level 2 conformance of minidom Initial Comment: This patch fixes a number of minidom bugs that occurred when trying to port 4XSLT to it: - addition of a DocumentFragment implementation and createDocumentFragment method - proper setting of ownerDocument for all nodes - setting of namespaceURI to None in Element as a class attribute - addition of setAttributeNodeNS and removeAttributeNodeNS as aliases for setAttributeNode and removeAttributeNode - support for inheriting from DOMImplementation to extend it with additional features (to override the Document class) in pulldom: - support for nodes (comment and PI) that occur before the document element; that became necessary as pulldom now delays creation of the document until it has the document element. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-12 10:30 Message: Logged In: YES user_id=21627 Since I can't get upload to work, the patch is at http://www.informatik.hu-berlin.de/~loewis/mini.diff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 From nobody@sourceforge.net Mon Mar 12 20:34:59 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 12 Mar 2001 12:34:59 -0800 Subject: [Patches] [ python-Patches-407965 ] Improve Level 2 conformance of minidom Message-ID: Patches #407965, was updated on 2001-03-12 10:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 Category: XML Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Martin v. Löwis Summary: Improve Level 2 conformance of minidom Initial Comment: This patch fixes a number of minidom bugs that occurred when trying to port 4XSLT to it: - addition of a DocumentFragment implementation and createDocumentFragment method - proper setting of ownerDocument for all nodes - setting of namespaceURI to None in Element as a class attribute - addition of setAttributeNodeNS and removeAttributeNodeNS as aliases for setAttributeNode and removeAttributeNode - support for inheriting from DOMImplementation to extend it with additional features (to override the Document class) in pulldom: - support for nodes (comment and PI) that occur before the document element; that became necessary as pulldom now delays creation of the document until it has the document element. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-12 12:34 Message: Logged In: YES user_id=3066 A quick overview and this look good -- check it in! ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-12 10:30 Message: Logged In: YES user_id=21627 Since I can't get upload to work, the patch is at http://www.informatik.hu-berlin.de/~loewis/mini.diff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 From nobody@sourceforge.net Mon Mar 12 21:07:40 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 12 Mar 2001 13:07:40 -0800 Subject: [Patches] [ python-Patches-407148 ] 'D' format option for Py_BuildValue Message-ID: Patches #407148, was updated on 2001-03-08 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407148&group_id=5470 Category: core (C code) Group: None Status: Closed Priority: 5 Submitted By: Walter Dörwald Assigned to: Fred L. Drake, Jr. Summary: 'D' format option for Py_BuildValue Initial Comment: This patch add the 'D' format specifier to Py_BuildValue for constructing complex Python numbers out of a Py_complex C structure. A patch to the documentation is included. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-12 13:07 Message: Logged In: YES user_id=3066 Checked in as Python/modsupport.c revision 2.55 and Doc/ext/ext.tex revision 1.94. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-03-11 16:19 Message: Logged In: YES user_id=6380 Looks good to me. Fred, can you do the honors? (If not, assign to me please!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407148&group_id=5470 From nobody@sourceforge.net Tue Mar 13 11:02:08 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 13 Mar 2001 03:02:08 -0800 Subject: [Patches] [ python-Patches-407965 ] Improve Level 2 conformance of minidom Message-ID: Patches #407965, was updated on 2001-03-12 10:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 Category: XML Group: None Status: Closed Priority: 5 Submitted By: Martin v. Löwis Assigned to: Martin v. Löwis Summary: Improve Level 2 conformance of minidom Initial Comment: This patch fixes a number of minidom bugs that occurred when trying to port 4XSLT to it: - addition of a DocumentFragment implementation and createDocumentFragment method - proper setting of ownerDocument for all nodes - setting of namespaceURI to None in Element as a class attribute - addition of setAttributeNodeNS and removeAttributeNodeNS as aliases for setAttributeNode and removeAttributeNode - support for inheriting from DOMImplementation to extend it with additional features (to override the Document class) in pulldom: - support for nodes (comment and PI) that occur before the document element; that became necessary as pulldom now delays creation of the document until it has the document element. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-13 03:02 Message: Logged In: YES user_id=21627 Committed as 1.28 of minidom and 1.20 of pulldom. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-03-12 12:34 Message: Logged In: YES user_id=3066 A quick overview and this look good -- check it in! ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-03-12 10:30 Message: Logged In: YES user_id=21627 Since I can't get upload to work, the patch is at http://www.informatik.hu-berlin.de/~loewis/mini.diff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407965&group_id=5470 From nobody@sourceforge.net Tue Mar 13 21:04:02 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 13 Mar 2001 13:04:02 -0800 Subject: [Patches] [ python-Patches-408326 ] slice objects comparable, not hashable Message-ID: Patches #408326, was updated on 2001-03-13 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Robin Thomas Assigned to: Nobody/Anonymous Summary: slice objects comparable, not hashable Initial Comment: This patch changes the behavior of slice objects in the following manner: - Slice objects are now comparable with other slice objects as though they were logically tuples of (start,stop,step). The tuple is not created in the comparison function, but the comparison behavior is logically equivalent. - Slice objects are not hashable. With the above change to being comparable, slice objects now cannot be used as keys in dictionaries. I ask that this patch be considered a "bug fix", rather than a change in functionality, and thus be included in 2.1b2 and forward. Other proposed changes to slicing and slice objects have been postponed until further discussion and the requisite PEP submission. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 From buildabizness@execs.com Tue Mar 13 20:49:10 2001 From: buildabizness@execs.com (buildabizness@execs.com) Date: Tue, 13 Mar 01 15:49:10 EST Subject: [Patches] Voted #1 Online Business In a Major Magazine! Message-ID: <200103131132.QAA02470@palogrande> Dear Friend, May I have your permission to send you FREE information for an exciting and very profitable SELF-RUN online business? It is truly the HOTTEST and the EASIEST home business today! Voted as #1 online business in a major business magazine! You could make up to $14,000 per month in your spare time! It is NOT a chain letter, NOT an illegal get-rich-quick scam. It is a legitimate online business which has been around for over FOUR YEARS! You'll find that this one is not anything like all those "refer your friends to our dot.com and get .25 cents commission" schemes. This is a REAL BUSINESS with a legitimate consumer product made easy by the power of the internet! And, you don't have to handle inventories and shipping or do face to face sales to get your guaranteed, high-percentage commissions each month either! Please click below to receive FREE VITAL INFORMATION: mailto:buildabizness@usa.com?subject=PleaseSend Send a "Blank" email with "please send" in the subject line. You will be glad that you did! Thank you and have a great day! With My Warmest Regards, Steve Fallin _______________________________________________________________ This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title 111, Section 301, Paragraph (a) (2) (C), passed by the 105th U.S. Congress and cannot be considered SPAM since it includes a removal mechanism. To unsubscribe, simply reply to this message and type "REMOVE" in the subject line. _______________________________________________________________Dear Friend, May I have your permission to send you FREE information for an exciting and very profitable SELF-RUN online business? It is truly the HOTTEST and the EASIEST home business today! Voted as #1 online business in a major business magazine! You could eventually be making up to $14,000 per month in your spare time! It is NOT a chain letter, NOT an illegal get-rich-quick scam. It is a legitimate online business which has been around for over FOUR YEARS! You'll find that this one is not anything like all those "refer your friends to our dot.com and gt .25 cents commission" schemes. This is a REAL BUSINESS with a legitimate consumer product made easy by the power of the internet! And, You don't have to handle inventories and shipping or do face to face sales to get your guaranteed, high-percentage commissions each month either! Please click below to receive FREE VITAL INFORMATION: mailto:buildabizness@usa.com?subject=PleaseSend Send a "Blank" email with "please send" in the subject line. You will be glad that you did! Thank you and have a great day! With My Warmest Regards, Steve Fallin ________________________________________________________ PS. This not "Spam," but a one-time opportunity to send for free information allowed under federal law. If you don't request the information by email to: buildabizness@usa.com or reply to this message in any way, you will not be contacted again. From noreply@sourceforge.net Wed Mar 14 21:31:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Mar 2001 13:31:38 -0800 Subject: [Patches] [ python-Patches-408597 ] quopri, soft line breaks and CRLF Message-ID: Patches item #408597, was updated on 2001-03-14 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408597&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: quopri, soft line breaks and CRLF Initial Comment: This patch fixes a small problem with quopri: Soft Line Breaks (i.e. lines ending with '='; see RFC 1521 2.1 Rule #5) do not work with CRLF line endings, because \r will not be stripped off from the read line. This patch fixes this problem by adding \r to the whitespace characters that are stripped off of the end of the line. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408597&group_id=5470 From noreply@sourceforge.net Wed Mar 14 23:00:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Mar 2001 15:00:49 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for nested list comprehensions (#406049) Message-ID: Patches item #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) >Summary: fix for nested list comprehensions (#406049) Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-11 16:22 Message: Logged In: YES user_id=6380 Assigned to jeremy. I've deleted the bogus files. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-05 10:56 Message: Logged In: YES user_id=6656 upload the right file... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-05 10:55 Message: Logged In: YES user_id=6656 trying again. passes make test now. now the numbers in the names of the list comp temporaries increase throughout the file being compiled. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From noreply@sourceforge.net Wed Mar 14 23:02:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Mar 2001 15:02:25 -0800 Subject: [Patches] [ python-Patches-408627 ] frame.lookup_name Message-ID: Patches item #408627, was updated on 2001-03-14 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Barry Warsaw (bwarsaw) Summary: frame.lookup_name Initial Comment: This method implements the functionality you want for string interpolation: given a frame, return the value that name is bound to in the frame's environment. Works for free variables. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 From noreply@sourceforge.net Thu Mar 15 03:13:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Mar 2001 19:13:39 -0800 Subject: [Patches] [ python-Patches-408696 ] Cygwin (ntsec mode) install patch Message-ID: Patches item #408696, was updated on 2001-03-14 19:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408696&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin (ntsec mode) install patch Initial Comment: This one line patch installs libpython2.1.dll with the execute priviledge set which is required for Cygwin Python to startup correctly when in ntsec mode. Comments in the Makefile seem to indicate that Cygwin operating in this mode is not the only system with this requirement. If interested, see the following for more details: http://sources.redhat.com/ml/cygwin/2001-03/msg00743.html To apply the patch: $ patch Patches item #408627, was updated on 2001-03-14 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jeremy Hylton (jhylton) Summary: frame.lookup_name Initial Comment: This method implements the functionality you want for string interpolation: given a frame, return the value that name is bound to in the frame's environment. Works for free variables. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-14 19:48 Message: Logged In: YES user_id=12800 Certainly seems to do what I want, thanks. Three questions, probably for the BDFL: - is lookup_name() the best name for the method? The underscore is a little ugly to me. - should lookup_name() take an optional failobj, a la dict.get() which, if provided and the name is missing returns failobj instead of raising NameError? NameError is fine if failobj is omitted. - does it make sense to be able to find out where a name was found, i.e. in which scope? I can't think of a particular use for this, but the API might be for frame.which_scope(name) to return an integer which signifies how many lexical scopes up the name was found. e.g. 0 == locals, 1 == immediately nested scope and so on. Maybe special value -1 means global. Ah, on second thought, that seems more confusing than necessary. Assigning back to Jeremy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 From noreply@sourceforge.net Thu Mar 15 05:53:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Mar 2001 21:53:35 -0800 Subject: [Patches] [ python-Patches-408627 ] frame.lookup_name Message-ID: Patches item #408627, was updated on 2001-03-14 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: frame.lookup_name Initial Comment: This method implements the functionality you want for string interpolation: given a frame, return the value that name is bound to in the frame's environment. Works for free variables. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2001-03-14 21:53 Message: Logged In: YES user_id=45338 I hate SourceForge. It just took three or four tries, reloading various pages on the looong path between the login screen and the patch detail screen, to convince it that i was logged in. Anyway, here's what i wanted to say: lookup() would be a fine name for a method, but then again, why not just use mp_subscript? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-14 19:48 Message: Logged In: YES user_id=12800 Certainly seems to do what I want, thanks. Three questions, probably for the BDFL: - is lookup_name() the best name for the method? The underscore is a little ugly to me. - should lookup_name() take an optional failobj, a la dict.get() which, if provided and the name is missing returns failobj instead of raising NameError? NameError is fine if failobj is omitted. - does it make sense to be able to find out where a name was found, i.e. in which scope? I can't think of a particular use for this, but the API might be for frame.which_scope(name) to return an integer which signifies how many lexical scopes up the name was found. e.g. 0 == locals, 1 == immediately nested scope and so on. Maybe special value -1 means global. Ah, on second thought, that seems more confusing than necessary. Assigning back to Jeremy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:16:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:16:30 -0800 Subject: [Patches] [ python-Patches-409043 ] Make _tkinter.c Tix aware Message-ID: Patches item #409043, was updated on 2001-03-15 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Make _tkinter.c Tix aware Initial Comment: A small patch to Modules/_tkinter.c to define the constant _tkinter.TIX_VERSION. This will allow Tkinter.py to know if Tix is present, and if do, define the Form geometry manager. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:21:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:21:46 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:23:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:23:21 -0800 Subject: [Patches] [ python-Patches-409045 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409045, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:23:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:23:31 -0800 Subject: [Patches] [ python-Patches-409046 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409046, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409046&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409046&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:32:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:32:27 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:32:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:32:39 -0800 Subject: [Patches] [ python-Patches-409049 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409049, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409049&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409049&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:35:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:35:38 -0800 Subject: [Patches] [ python-Patches-409049 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409049, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409049&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-15 22:35 Message: Logged In: YES user_id=33229 Duplicate of #409048 - sorry SF is f*&%ing up again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409049&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:50:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:50:44 -0800 Subject: [Patches] [ python-Patches-409053 ] Add Tix.py to Lib/lib-tk Message-ID: Patches item #409053, was updated on 2001-03-15 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Add Tix.py to Lib/lib-tk Initial Comment: At Python9, Guido asked me to contribute Tix into the core. Attached is Tix.py, which should go into Lib/lib-tk It should work for any 2.x, but should have the associated patches I just added apllied as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:54:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:54:11 -0800 Subject: [Patches] [ python-Patches-409055 ] Tix Demos Message-ID: Patches item #409055, was updated on 2001-03-15 22:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Demos Initial Comment: A tgz of demos for Tix. They should just drop into Demos/tix. The demos are good for any 2.x version, but the documentation is 2.1 specific as it assumes the associated patches I contruibted previous have been applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 From noreply@sourceforge.net Fri Mar 16 06:57:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Mar 2001 22:57:17 -0800 Subject: [Patches] [ python-Patches-409046 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409046, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409046&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-15 22:57 Message: Logged In: YES user_id=33229 Duplicate of #409045 - sorry SF is screwing up - it's just giving a null/empty document in reply to patch submissions, even though they seem to be successful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409046&group_id=5470 From noreply@sourceforge.net Fri Mar 16 10:39:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Mar 2001 02:39:27 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Fri Mar 16 11:52:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Mar 2001 03:52:02 -0800 Subject: [Patches] [ python-Patches-408696 ] Cygwin (ntsec mode) install patch Message-ID: Patches item #408696, was updated on 2001-03-14 19:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408696&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin (ntsec mode) install patch Initial Comment: This one line patch installs libpython2.1.dll with the execute priviledge set which is required for Cygwin Python to startup correctly when in ntsec mode. Comments in the Makefile seem to indicate that Cygwin operating in this mode is not the only system with this requirement. If interested, see the following for more details: http://sources.redhat.com/ml/cygwin/2001-03/msg00743.html To apply the patch: $ patch Comment By: Neil Schemenauer (nascheme) Date: 2001-03-16 03:52 Message: Logged In: YES user_id=35752 Checked in (Makefile.pre.in r1.30). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408696&group_id=5470 From noreply@sourceforge.net Fri Mar 16 12:47:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Mar 2001 04:47:14 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Fri Mar 16 12:50:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Mar 2001 04:50:42 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Sat Mar 17 00:51:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Mar 2001 16:51:47 -0800 Subject: [Patches] [ python-Patches-409287 ] ssl fix when using _socketobject Message-ID: Patches item #409287, was updated on 2001-03-16 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: ssl fix when using _socketobject Initial Comment: On windows and other platforms _socketobject instances are used instead of the raw extension type. This breaks the _socket.ssl function which is expecting an extension type parameter. This patch makes a wrapper for socket.ssl similar to socket.socket when _socketobjects are used. This patch is for 2.0 but it looks like it will work the same in 2.1 *** socket.orig.py Fri Mar 16 16:23:38 2001 --- socket.py Fri Mar 16 16:25:52 2001 *************** *** 51,58 **** --- 51,67 ---- except NameError: _realsocketcall = socket + try: + _realsslcall + except NameError: + _realsslcall = ssl + def socket(family, type, proto=0): return _socketobject(_realsocketcall(family, type, proto)) + + def ssl(sock, keyfile=None, certfile=None): + return _realsslcall(sock._sock, keyfile, certfile) + # WSA error codes ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 From noreply@sourceforge.net Sat Mar 17 03:29:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Mar 2001 19:29:52 -0800 Subject: [Patches] [ python-Patches-409307 ] Create parsermodule.h Message-ID: Patches item #409307, was updated on 2001-03-16 19:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409307&group_id=5470 Category: Modules Group: None Status: Open Priority: 7 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (this is my second try...if it comes through twice, close one of them!) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The attached patch describes the changes to parsermodule.c. Here's what should be in include/parsermodule.h #ifndef Py_PARSEROBJECT_H #define Py_PARSEROBJECT_H #ifdef __cplusplus extern "C" { #endif /* There are two types of intermediate objects we're interested in: * 'eval' and 'exec' types. These constants can be used in the ast_type * field of the object type to identify which any given object represents. * * The PyAST_FRAGMENT type is not currently supported. Maybe not useful? * Haven't decided yet. */ #define PyAST_EXPR 1 #define PyAST_SUITE 2 #define PyAST_FRAGMENT 3 typedef struct _PyAST_Object { PyObject_HEAD /* standard object header */ node* ast_node; /* the node* returned by the parser */ int ast_type; /* EXPR or SUITE ? */ } PyAST_Object; extern DL_IMPORT(PyObject *) parser_newastobject(node *ast, int type); #ifdef __cplusplus } #endif #endif /* !Py_PARSEROBJECT_H */ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409307&group_id=5470 From noreply@sourceforge.net Sat Mar 17 05:04:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Mar 2001 21:04:15 -0800 Subject: [Patches] [ python-Patches-407764 ] allow whitespace lines for doctest tests Message-ID: Patches item #407764, was updated on 2001-03-11 13:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Tim Peters (tim_one) Summary: allow whitespace lines for doctest tests Initial Comment: Currently doctest.py does not allow individual tests to have all-whitespace output lines. This patch proposes a fix for this. With this patch a leading '.' on a doctest output line, if and only if the tests are indented, will signal that following whitespace *is* the expected output. For example, currently this cannot be doctest'ed """ >>> print "\nhello\n" hello >>> """ But with this patch *this* can be: # file test_doctest.py """ >>> print "\nhello\n" . hello . >>> """ def _test(): import doctest, test_doctest return doctest.testmod(test_doctest) if __name__ == "__main__": _test() ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-16 21:04 Message: Logged In: YES user_id=31435 Trent, yuck. doctests are primarily documentation, and there's nothing about "." that suggests-- let alone screams --"ah, this line is really a blank line, not the period that it sure looks like". Too confusing. I'd be happy with this if it *screamed* "blank line", though! For example, accept as meaning it's really a blank line. In that case, though, note that: 1. The restriction about blank lines is documented in both doctest's docstrings and in the Library Manual, so this would also need doc changes in both places. and 2. doctest is self-testing, i.e. the standard test for doctest simply runs doctest on doctest. So in the very same place you document your blank line convention in the doctest docstring, you should also include an executable doctest example in the docstring. Then the standard test_doctest.py will verify that it works exactly as advertised forever more. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-11 13:40 Message: Logged In: YES user_id=34892 Grrr, the code I put in the comment is supposed to be indented of course. I will attach the test_doctest.py to clarify. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 From noreply@sourceforge.net Sat Mar 17 16:38:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Mar 2001 08:38:46 -0800 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches item #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Moshe Zadka (moshez) >Assigned to: Moshe Zadka (moshez) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: A.M. Kuchling (akuchling) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #409444, was updated on 2001-03-17 12:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409444&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Greg Ward (gward) Summary: Redirect stdout in distutils.spawn Initial Comment: The attached patch (yeah, right) modifies distutils/spawn.py to add the ability to redirect standard output to a file, at least on POSIX platforms. This would be needed for Barry's patch to support shar as a Distutils output format. Questions: * Is this a good idea? * Is the interface right? Should it take a file object instead of a filename? (It therefore always uses 'wb' mode, which may be bad.) * Can someone contribute the required changes to make this work on NT? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409444&group_id=5470 From noreply@sourceforge.net Sat Mar 17 20:47:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Mar 2001 12:47:31 -0800 Subject: [Patches] [ python-Patches-405016 ] small setup.py patch for VPATH build Message-ID: Patches item #405016, was updated on 2001-02-28 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: A.M. Kuchling (akuchling) Summary: small setup.py patch for VPATH build Initial Comment: This patch against the current CVS prepends `srcdir' to the `scripts' variable. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 12:47 Message: Logged In: YES user_id=11375 This is fixed by a different change to setup.py. It should work fine in 2.1b1 and in the current CVS. ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer (mfx) Date: 2001-02-28 15:13 Message: Logged In: YES user_id=12151 Index: dist/src/setup.py =================================================================== RCS file: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.33 diff -r1.33 setup.py 597a598 > (srcdir,) = sysconfig.get_config_vars('srcdir') 606c607 < scripts = ['Tools/scripts/pydoc'] --- > scripts = [os.path.join(srcdir, 'Tools/scripts/pydoc')] ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer (mfx) Date: 2001-02-28 15:11 Message: Logged In: YES user_id=12151 (the new sourceforge code is confusing me...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 From noreply@sourceforge.net Sun Mar 18 05:23:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Mar 2001 21:23:55 -0800 Subject: [Patches] [ python-Patches-403640 ] incomplete proxy handling in URLLIB Message-ID: Patches item #403640, was updated on 2001-02-06 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: incomplete proxy handling in URLLIB Initial Comment: under WinNT, the proxy code takes the proxy values from the registry, but does *not* check for the proxy override settings. The supplied patch does take care of it and works for me. Not very sophisticated, but operational. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-17 21:23 Message: Logged In: YES user_id=31435 Back to you! I've spent enough time on it, but I don't know this code, and it turns out I never get into it anyway. @Home uses the AutoConfigURL registry gimmick rather than ProxyEnable (which is 0 on my box) and ProxyOverride (which doesn't exist on my box). Even if they did exist, the new proxy_bypass() routine isn't called if the url passed to open_http() is a string, and it always is a string for me. Trying to trace *that* back, this is apparently because the NT getproxies() function returns {}, and again because @Home isn't enabling ProxyEnable. So best I can say is that this code doesn't hurt me. Note that there are jarring style differences with surrounding code, primarily use of Capitalized words for local vrbl names. Also lines and comments spilling past column 80. The list() call in list(proxyOverrd.split(';')) doesn't appear to make sense (.split() returns a list!). For that matter proxyOverrd is an ugly abbreviation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 23:07 Message: Logged In: YES user_id=6380 Tim, you seem to be using a proxy, so maybe you can give this a try? Also, it has Win specific code (_winreg usage). If you can't or don't want to, please give it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 From noreply@sourceforge.net Sun Mar 18 08:45:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 00:45:45 -0800 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches item #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: Moshe Zadka (moshez) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-03-18 00:45 Message: Logged In: YES user_id=11645 Checked in ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #409504, was updated on 2001-03-18 02:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 Category: demos and tools Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Fix freeze: regex, continuation lines Initial Comment: This patch corrects two bugs in freeze: it won't use freeze anymore, and variables that span over several lines using \-continuation are extracted correctly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 From noreply@sourceforge.net Sun Mar 18 10:58:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 02:58:30 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Sun Mar 18 10:59:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 02:59:39 -0800 Subject: [Patches] [ python-Patches-409046 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409046, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409046&group_id=5470 Category: Tkinter Group: None >Status: Closed Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:59 Message: Logged In: YES user_id=21627 Closed as a duplicate. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-15 22:57 Message: Logged In: YES user_id=33229 Duplicate of #409045 - sorry SF is screwing up - it's just giving a null/empty document in reply to patch submissions, even though they seem to be successful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409046&group_id=5470 From noreply@sourceforge.net Sun Mar 18 11:06:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 03:06:18 -0800 Subject: [Patches] [ python-Patches-409045 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409045, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:06 Message: Logged In: YES user_id=21627 There is no need to split your patches into such small pieces. Instead, everything dealing with Tix should be one patch (including changes to Modules/Setup.dist you may want to make). If you want to follow the route of linking Tix statically (which I'd discourage), you should use the same strategy to find the current Tix version as done to find the current Tk version: given the Tk version, iterate over candidate Tix versions and find the most recent one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 From noreply@sourceforge.net Sun Mar 18 11:07:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 03:07:08 -0800 Subject: [Patches] [ python-Patches-409049 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409049, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409049&group_id=5470 Category: Tkinter Group: None >Status: Closed Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:07 Message: Logged In: YES user_id=21627 Closed as a duplicate. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-15 22:35 Message: Logged In: YES user_id=33229 Duplicate of #409048 - sorry SF is f*&%ing up again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409049&group_id=5470 From noreply@sourceforge.net Sun Mar 18 11:13:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 03:13:57 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Sun Mar 18 11:20:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 03:20:17 -0800 Subject: [Patches] [ python-Patches-409053 ] Add Tix.py to Lib/lib-tk Message-ID: Patches item #409053, was updated on 2001-03-15 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Add Tix.py to Lib/lib-tk Initial Comment: At Python9, Guido asked me to contribute Tix into the core. Attached is Tix.py, which should go into Lib/lib-tk It should work for any 2.x, but should have the associated patches I just added apllied as well. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:20 Message: Logged In: YES user_id=21627 Looks good, it has roughly the same contents that we use as well. To bring up dynamic loading again, we have @@ -69,9 +98,6 @@ self.widgetName = widgetName Widget._setup(self, master, cnf) - # Must load the definitions of all of the Tix commands - self.tk.eval("package require Tix") - # If widgetName is None, this is a dummy creation call where the # corresponding Tk widget has already been created by Tix if widgetName: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 From noreply@sourceforge.net Sun Mar 18 11:22:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 03:22:09 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Sun Mar 18 22:36:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 14:36:04 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:36 Message: Logged In: YES user_id=33229 I would love to load Tix using package require, because that would be a "good thing", but there are some details: 1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking. My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved. I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach: 1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach. These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored. Don't hesitate to send me email as well idiscovery@users.sourceforge.net Mike. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Sun Mar 18 22:42:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 14:42:52 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Sun Mar 18 22:47:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 14:47:23 -0800 Subject: [Patches] [ python-Patches-409053 ] Add Tix.py to Lib/lib-tk Message-ID: Patches item #409053, was updated on 2001-03-15 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Add Tix.py to Lib/lib-tk Initial Comment: At Python9, Guido asked me to contribute Tix into the core. Attached is Tix.py, which should go into Lib/lib-tk It should work for any 2.x, but should have the associated patches I just added apllied as well. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:47 Message: Logged In: YES user_id=33229 It's safe to add this anyway, even if we use static packages, so go ahead with this change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:20 Message: Logged In: YES user_id=21627 Looks good, it has roughly the same contents that we use as well. To bring up dynamic loading again, we have @@ -69,9 +98,6 @@ self.widgetName = widgetName Widget._setup(self, master, cnf) - # Must load the definitions of all of the Tix commands - self.tk.eval("package require Tix") - # If widgetName is None, this is a dummy creation call where the # corresponding Tk widget has already been created by Tix if widgetName: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 From noreply@sourceforge.net Sun Mar 18 22:53:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 14:53:46 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:53 Message: Logged In: YES user_id=33229 Opps sorry - here's the context diff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Sun Mar 18 23:10:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 15:10:46 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:10 Message: Logged In: YES user_id=6380 Very close. Thanks, Ping! Mandatory improvement:most of the times where you use fprintf(stderr, ...) you should be using PySys_WriteStderr(...). The only time when it's OK to use stderr directly is is when sys.stderr is not found. An idea which I'm not sure of: maybe the PyErr_Display() function could take a PyObject * 4th argument being the file object to which the traceback should be written. This makes the logic of its callers a bit more convoluted, unless you let it default to NULL (which might be the best thing anyway). Also... I guess we need a few lines of documentation for sys.excepthook, for PyErr_Display(), and for the changed semantics of PyErr_Print[Ex](). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Sun Mar 18 23:33:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 15:33:27 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-18 15:33 Message: Logged In: NO PS-- I would suggest to store a copy in sys.__excepthook__, just like sys.__stdout__. Guido (too lazy to log in on SF) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:10 Message: Logged In: YES user_id=6380 Very close. Thanks, Ping! Mandatory improvement:most of the times where you use fprintf(stderr, ...) you should be using PySys_WriteStderr(...). The only time when it's OK to use stderr directly is is when sys.stderr is not found. An idea which I'm not sure of: maybe the PyErr_Display() function could take a PyObject * 4th argument being the file object to which the traceback should be written. This makes the logic of its callers a bit more convoluted, unless you let it default to NULL (which might be the best thing anyway). Also... I guess we need a few lines of documentation for sys.excepthook, for PyErr_Display(), and for the changed semantics of PyErr_Print[Ex](). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Sun Mar 18 23:44:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 15:44:21 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 15:44 Message: Logged In: YES user_id=33229 > I'd rather encourage assigning to > Widget.__bases__ (to get Form into the list of base > classes), instead of putting Tix code into Tkinter. Either way is fine with me. I prefer the more explicit way of showing Tkinter.py readers where the form geometry manager fits in, and I find messing with __foobars__ to be a less visible way of doing magic, but it's up to you. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:53 Message: Logged In: YES user_id=33229 Opps sorry - here's the context diff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Sun Mar 18 23:57:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 15:57:52 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:57 Message: Logged In: YES user_id=6380 Ping, I was testing this in a loop looking for leaks (none found BTW) and I noticed that it couldn't be killed by control-C. Can you see a reason why? Also, I was looking at the Python code in traceback.py and it has a limit on how many frames it prints (which defaults to sys.tracebacklimit). Would it make sense to be able to pass that into sys.excepthook() as well? Note; I'm seeing enough little questions that make me think this is best left until after 2.1 is released... Would you be very disappointed? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-18 15:33 Message: Logged In: NO PS-- I would suggest to store a copy in sys.__excepthook__, just like sys.__stdout__. Guido (too lazy to log in on SF) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:10 Message: Logged In: YES user_id=6380 Very close. Thanks, Ping! Mandatory improvement:most of the times where you use fprintf(stderr, ...) you should be using PySys_WriteStderr(...). The only time when it's OK to use stderr directly is is when sys.stderr is not found. An idea which I'm not sure of: maybe the PyErr_Display() function could take a PyObject * 4th argument being the file object to which the traceback should be written. This makes the logic of its callers a bit more convoluted, unless you let it default to NULL (which might be the best thing anyway). Also... I guess we need a few lines of documentation for sys.excepthook, for PyErr_Display(), and for the changed semantics of PyErr_Print[Ex](). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Sun Mar 18 23:59:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 15:59:24 -0800 Subject: [Patches] [ python-Patches-401264 ] Attribute Doc-Strings (PEP 224) Message-ID: Patches item #401264, was updated on 2000-08-23 02:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401264&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Guido van Rossum (gvanrossum) Summary: Attribute Doc-Strings (PEP 224) Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:59 Message: Logged In: YES user_id=6380 I'm rejecting this now. I just don't like this PEP. See python-dev for motivations. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-02-10 07:03 Message: Reopened so I can think about how to respond. My gut still says not now. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-01-04 11:43 Message: Perhaps we should rediscuss the PEP on python-dev ? I really have a strong need to add documentation to attributes in a way which is compatible with the existing __doc__ string facilities, so I'd appreciate feedback. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 07:53 Message: This is (poresumably) for PEP 224, which is marked as pie-in-the-sky and thus won't be considered for 2.1. Really, I should pronounce on that PEP (I don't like it very much but haven't found the right argument to reject it :-) so this patch can either go in be rejected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-23 08:21 Message: Postponed due to 2.0 feature freeze and assigned to the release manager for re-opening. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2000-08-23 02:22 Message: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401264&group_id=5470 From noreply@sourceforge.net Mon Mar 19 00:02:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 16:02:08 -0800 Subject: [Patches] [ python-Patches-401702 ] Modify co_filename in frozen programs Message-ID: Patches item #401702, was updated on 2000-09-29 04:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401702&group_id=5470 Category: demos and tools Group: None Status: Open >Priority: 9 Submitted By: Lawrence Hudson (lhudson) Assigned to: Guido van Rossum (gvanrossum) Summary: Modify co_filename in frozen programs Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:02 Message: Logged In: YES user_id=6380 Sure, I see no problem with this patch. I'll see if I can check it in. If someone else who likes to hack freeze would have it, please go ahead! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 23:12 Message: Logged In: YES user_id=6380 Shit. Missed the deadline again. Will try before b2... :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 14:45 Message: No time to review this before the 2.1a1 release; I'll do this for 2.1a2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 07:53 Message: I'm taking this, on the assumption that Mark's too busy and freeze is our shared responsibility. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-01-18 15:57 Message: (somewhat) randomly reassigned; don't have time to look at this ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-25 04:19 Message: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ---------------------------------------------------------------------- Comment By: Lawrence Hudson (lhudson) Date: 2000-10-25 01:36 Message: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\python\lib\") 'c:\python\lib' >>> os.path.normpath("c:\python\Lib\") 'c:\python\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-23 12:33 Message: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-29 07:28 Message: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ---------------------------------------------------------------------- Comment By: Lawrence Hudson (lhudson) Date: 2000-09-29 04:39 Message: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401702&group_id=5470 From noreply@sourceforge.net Mon Mar 19 00:08:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 16:08:46 -0800 Subject: [Patches] [ python-Patches-403640 ] incomplete proxy handling in URLLIB Message-ID: Patches item #403640, was updated on 2001-02-06 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: incomplete proxy handling in URLLIB Initial Comment: under WinNT, the proxy code takes the proxy values from the registry, but does *not* check for the proxy override settings. The supplied patch does take care of it and works for me. Not very sophisticated, but operational. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:08 Message: Logged In: YES user_id=6380 Back to you, Tim. I'm also an @home user so I can't test this either. I agree with the style comments. Also, it translates a pattern to regular expression; an easier way to do this is to use fnmatch (which also takes care of the case insensitive match when it's on Windows). Would the original submitter care to clean up the code according to the (Tim's & my) comments? Otherwise I think this is sufficiently low priority that I'm not going to move heaven & earth to get it into 2.1b2 (this Friday), and after that I'm not going to allow *anything* new in the code base for 2.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 21:23 Message: Logged In: YES user_id=31435 Back to you! I've spent enough time on it, but I don't know this code, and it turns out I never get into it anyway. @Home uses the AutoConfigURL registry gimmick rather than ProxyEnable (which is 0 on my box) and ProxyOverride (which doesn't exist on my box). Even if they did exist, the new proxy_bypass() routine isn't called if the url passed to open_http() is a string, and it always is a string for me. Trying to trace *that* back, this is apparently because the NT getproxies() function returns {}, and again because @Home isn't enabling ProxyEnable. So best I can say is that this code doesn't hurt me. Note that there are jarring style differences with surrounding code, primarily use of Capitalized words for local vrbl names. Also lines and comments spilling past column 80. The list() call in list(proxyOverrd.split(';')) doesn't appear to make sense (.split() returns a list!). For that matter proxyOverrd is an ugly abbreviation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 23:07 Message: Logged In: YES user_id=6380 Tim, you seem to be using a proxy, so maybe you can give this a try? Also, it has Win specific code (_winreg usage). If you can't or don't want to, please give it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 From noreply@sourceforge.net Mon Mar 19 00:09:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 16:09:27 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches item #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open >Priority: 1 Submitted By: Thomas Wouters (twouters) Assigned to: Guido van Rossum (gvanrossum) Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1 is released. Status set to postponed and priority lowered. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From noreply@sourceforge.net Mon Mar 19 02:23:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Mar 2001 18:23:53 -0800 Subject: [Patches] [ python-Patches-405228 ] split Telnet class into TelnetBase Message-ID: Patches item #405228, was updated on 2001-03-01 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Guido van Rossum (gvanrossum) Summary: split Telnet class into TelnetBase Initial Comment: I've been asked to make telnet, ssh, bash and rpcclient (http://www.samba-tng.org), http requests and possibly much more all look seamlessly like telnet. That means splitting telnetlib.py's Telnet class down into a base class. I need the write, read_until, expect and friends, but did not want to do a total rewrite / total pain-in-the-neck cut/paste job on telnetlib.py just to fulfil the requirements. I have noticed that someone wrote an scp class, already before: it's available on parnassus. it wraps scp in popen. with this TelnetBase class, doing the same thing will be trivial _and_ you get the exact same look and functionality as if it was a Telnet() instance. well, it makes _me_ happy enough to submit this patch. copyright is hereby assigned to Guido van Rossum. authorship must remain as-is. have fun, luke ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 18:23 Message: Logged In: YES user_id=6380 This version of the patch looks like it needs a lot of work. Sent comments directly to author. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 18:47 Message: Logged In: YES user_id=6380 I'll try to do this after b1 is released. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-03-01 11:32 Message: Logged In: YES user_id=80200 good grief. what the hell is wrong with sourceforge??? you can't upload files! grrr. diff -u will be sent to patches@python.org. grrr ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 From Remote Backup Sales" Your Own Remote Backup Business

The most valuable asset most businesses own is completely UNPROTECTED!

YOU CAN SAVE IT... AND MAKE MONEY!

Look, I know you get dozens of emails every day hawking "Get Rich Quick" schemes, chain letter offers, and LOTS of other absurd scams that promise to make you rich overnight with no investment and no work.

My offer is NOT one of those. What I'm offering is a straightforward computer-based service that you can run full-or part-time like a regular business. This service runs automatically while you sleep, vacation, or work a "regular" job. It provides a valuable new service for businesses in your area.

I'm offering a high-tech, low-maintenance, work-from-anywhere business that can bring in a nice comfortable additional income for your family. I did it for eight years. Since I started inviting others to join me, I've helped over 4500 do the same.


I invented it, and it's called a "Remote Backup Service." You may have read about it in Entrepreneur Magazine, Inc, Home Office Computing, HomePC, or any of dozens of city newspapers. I've been written up many times in books, magazines, and newspapers.

Read what the Media say...

PC World August, 2000 Hassle-Free Backups
"...we strongly endorse online backup services as one component of a sound backup strategy ...they're an excellent way to store important files where you know you can get to them, no matter what unpleasant disaster befalls."

Computer User April, 1999 Remote Backup Services
 "Picture this: You run a small business and you back up your data on Zip disks. You hoard those disks in a storage cabinet out in the hall. Everything's running smoothly until an earthquake rips your building in half and the storage cabinet tumbles into the fiery depths of the earth. Where's your data now?"

Turn Your Talents Into Profits Darcie Sanders & Martha M Bullen
"This is an ideal business for someone with reduced mobility or a hermit-type personality who doesn't want the kind of home business that will bring a lot of clients actually knocking on his door. Since most of your clients will already be on-line, you can even advertise your business via computer… … Your Remote Backup Service is a form of business insurance for the Information age."

It works like this: At night, while you sleep and your clients' businesses are closed, your computer accepts backup data sent automatically by the clients' computers. You store this data for your clients on your computer. Your clients pay you a monthly service fee, and that's about it.

This business might not sound very exciting, but believe me, it is growing VERY rapidly. It can generate a steadily increasing, permanent source of reliable, recurring monthly income for your family that will improve your standard of living, and WON'T cost a fortune to start or run, ESPECIALLY if you already have a computer and modem; and I assume you do, since you received this EMail. It won't take up all your time - in fact, the service almost runs itself.


What Current RBS Providers Say

I have started looking over the business kit and all I can say is WOW!!! Your kit is priceless. It is as complete as it gets. G.B. QC CANADA

Rob, It took you a good five minutes to respond! Once again I'm totally blown away by your customer service. That's something rare these days and it's very impressive. I'll strive for the same customer service in my own RBS business. I'm looking forward to future dealings with you. S.M. NY USA

…The application performed very well on the test that I scheduled for 1 PM. File backed up to server without a hitch. I then restored the file with no problem. Wonderful result. Boss is happy, owner is happy! R.B. CA USA

Thanks guys for all your help this morning. You have helped me enormously with getting my system up and running. It's great to know that there is such strong support behind the product! A.G. NSW AUS

I'm sure you already know it but you have a great tech support department in John. Quick, knowledgeable responses & a wealth of information, day or night. Amazing stuff. Thanks again, A.C. FL USA

I am about half way through the RBS book. What a wonderful book!! It has so much information, in an easy to read format. I am really getting excited about this business. I know it will be a success, I am just a little worried about growing too big, too fast! D.A. WA USA

I've had my Business Kit for a few weeks. Spending a lot of time reading conference material which I find extremely insightful. In my years in business I have never experienced such an accessible "support group" (other QTI customers). M.S. MI USA

Jan, One thing I will say about the company you work for - I am getting the very best service I have ever had with a company in a very long time. Thanks for your help very much! C.W. TX USA


My staff and I are committed to making YOU successful in our industry. We KNOW how to do it, because we've done it ourselves. Many of our RBS Providers have 50, 60, 100, 200 and 300 clients after only a few months in business. You can, too. Let us show YOU how to make YOUR computer earn money while YOU sleep!



Reply with REMOVE in the subject, or click this button to be removed from future mailings
From bogus@does.not.exist.com Mon Mar 19 05:05:52 2001 From: bogus@does.not.exist.com () Date: Mon, 19 Mar 2001 02:05:52 -0300 Subject: [Patches] MUDE SUA VIDA APARTIR DE AGORA Message-ID: ENTRE NESSA MAIS NOVA MANIA ONDE OS INTERNAUTAS GANHAM POR APENAS ESTAR CONECTADOS A INTERNET !!!! EU GANHO EM MEDIA CERCA DE 2 MIL REAIS MENSAL, ISSO MESMO !!! GANHE VOCE TAMBEM ... O QUE VOCE ESTA ESPERANDO ? 'E TOTALMENTE GRATIS, NAO CUSTA NADA TENTAR , VOCE PERDE APENAS 5 MINUTOS DE SEU TEMPO PARA SE CADASTRAR, POREM NO 1 MES VOCE JA VE O RESULTADO ( R$ 2.000,00 ) ISSO MESMO, ISSO E'+- O QUE EU TIRO MENSALMENTE, EXISTE PESSOAS QUE CONSEGUEM O DOBRO E ATE MESMO O TRIPLO !!!! BASTA ENTRAR EM UM DOS SITES ABAIXO PARA COMECAR A GANHAR --> www.muitodinheiro.com www.dinheiromole.com www.granaajato.cjb.net ENGLISH VERSION $$$ MAKE A LOT OF MONEY $$$ Are you of those that thinks to win money in the internet it doesn't pass of a farce and what will you never receive anything? ENTER IN - www.muitodinheiro.com www.dinheiromole.com www.granaajato.cjb.net From noreply@sourceforge.net Mon Mar 19 18:43:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 10:43:31 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-19 10:43 Message: Logged In: YES user_id=21627 For 1), I'd say this is historic garbage (I added some of it myself), so don't be afraid to rip it out. tkappinit.c predates the times that Tcl could do dynamic loading. Also, there is no need to operate the same way for all packages; just fix Tix for now. For 2), there are more problems when freezing: In Python 2.1, setup.py will build _tkinter as a dynamic module, and you can't freeze them, anyway. So anybody who wants to freeze would need a build where _tkinter is listed in Modules/Setup. Furthermore, you typically need Tix SAM libraries, or else the binary won't be stand-alone. Then you need static versions of libtcl.a, not shared ones. Anybody who wants to freeze with Tix needs a fair amount of local configuration, so supporting freeze is more complicated. For 3), if Tix does not appear in the C files at all, it can be removed from the .dsp file as well. For setup.py: You still can use Setup if you want to. The problem I see with static linkage that _tkinter then depends on Tix, so to install Python, you'll need to install Tix first; if you build Python not to depend on Tix, you can't use it even when it gets installed. Since most people use binary distributions, they get more out of dynamic loading than they'd get from static linking. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:36 Message: Logged In: YES user_id=33229 I would love to load Tix using package require, because that would be a "good thing", but there are some details: 1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking. My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved. I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach: 1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach. These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored. Don't hesitate to send me email as well idiscovery@users.sourceforge.net Mike. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Mon Mar 19 20:32:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 12:32:21 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for nested list comprehensions (#406049) Message-ID: Patches item #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: fix for nested list comprehensions (#406049) Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-03-19 12:32 Message: Logged In: YES user_id=31392 The patch should fix the symbol table, not the compiler. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-11 16:22 Message: Logged In: YES user_id=6380 Assigned to jeremy. I've deleted the bogus files. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-05 10:56 Message: Logged In: YES user_id=6656 upload the right file... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-05 10:55 Message: Logged In: YES user_id=6656 trying again. passes make test now. now the numbers in the names of the list comp temporaries increase throughout the file being compiled. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From noreply@sourceforge.net Mon Mar 19 20:33:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 12:33:28 -0800 Subject: [Patches] [ python-Patches-408627 ] frame.lookup_name Message-ID: Patches item #408627, was updated on 2001-03-14 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: frame.lookup_name Initial Comment: This method implements the functionality you want for string interpolation: given a frame, return the value that name is bound to in the frame's environment. Works for free variables. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-03-19 12:33 Message: Logged In: YES user_id=31392 We decided to scrap this approach, because it does a linear search over the names in the code object to figure out the right scope. If you look up all the names, this has quadratic cost. Instead, we'll create a dictionary with all the name bindings. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-14 21:53 Message: Logged In: YES user_id=45338 I hate SourceForge. It just took three or four tries, reloading various pages on the looong path between the login screen and the patch detail screen, to convince it that i was logged in. Anyway, here's what i wanted to say: lookup() would be a fine name for a method, but then again, why not just use mp_subscript? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-14 19:48 Message: Logged In: YES user_id=12800 Certainly seems to do what I want, thanks. Three questions, probably for the BDFL: - is lookup_name() the best name for the method? The underscore is a little ugly to me. - should lookup_name() take an optional failobj, a la dict.get() which, if provided and the name is missing returns failobj instead of raising NameError? NameError is fine if failobj is omitted. - does it make sense to be able to find out where a name was found, i.e. in which scope? I can't think of a particular use for this, but the API might be for frame.which_scope(name) to return an integer which signifies how many lexical scopes up the name was found. e.g. 0 == locals, 1 == immediately nested scope and so on. Maybe special value -1 means global. Ah, on second thought, that seems more confusing than necessary. Assigning back to Jeremy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:11:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:11:11 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:12:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:12:18 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:14:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:14:10 -0800 Subject: [Patches] [ python-Patches-406076 ] fix for nested list comprehensions (#406049) Message-ID: Patches item #406076, was updated on 2001-03-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: fix for nested list comprehensions (#406049) Initial Comment: fix for #406049. duh! ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-19 12:32 Message: Logged In: YES user_id=31392 The patch should fix the symbol table, not the compiler. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-11 16:22 Message: Logged In: YES user_id=6380 Assigned to jeremy. I've deleted the bogus files. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-05 10:56 Message: Logged In: YES user_id=6656 upload the right file... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-05 10:55 Message: Logged In: YES user_id=6656 trying again. passes make test now. now the numbers in the names of the list comp temporaries increase throughout the file being compiled. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406076&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:16:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:16:08 -0800 Subject: [Patches] [ python-Patches-405853 ] Allow jython to use site.py Message-ID: Patches item #405853, was updated on 2001-03-04 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to use site.py Initial Comment: Change 1: Not all 'modules' in sys.modules have a sensible __file__ attribute. Some of our java package can have the __file__ attribute set to None. Change 2: In jython we have the jython license file in and the CPython license file in /Lib. By reversing the search sequence jython will find and show the jython license file before the CPython file. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-03-04 09:48 Message: Logged In: YES user_id=4201 Forgot to mark the upload checkbox. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:16:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:16:07 -0800 Subject: [Patches] [ python-Patches-405851 ] Allow jython to complete test_strftime Message-ID: Patches item #405851, was updated on 2001-03-04 09:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to complete test_strftime Initial Comment: Java always eun with a national locale. As a result the default strings from the "time" module is national. This path will assign a US locale and allow a successful test even when running with a non-us computer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:16:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:16:52 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Tim Peters (tim_one) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:16:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:16:21 -0800 Subject: [Patches] [ python-Patches-406248 ] Enable Weak References to Functions Message-ID: Patches item #406248, was updated on 2001-03-06 01:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406248&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Phil Thompson (rega39) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Enable Weak References to Functions Initial Comment: The patch enables weak references for functions, mainly useful for lambda functions. Without this patch it is possible for a PyQt programmer to write scripts that will seg fault the interpreter. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406248&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:17:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:17:24 -0800 Subject: [Patches] [ python-Patches-409043 ] Make _tkinter.c Tix aware Message-ID: Patches item #409043, was updated on 2001-03-15 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Make _tkinter.c Tix aware Initial Comment: A small patch to Modules/_tkinter.c to define the constant _tkinter.TIX_VERSION. This will allow Tkinter.py to know if Tix is present, and if do, define the Form geometry manager. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:17:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:17:25 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-19 10:43 Message: Logged In: YES user_id=21627 For 1), I'd say this is historic garbage (I added some of it myself), so don't be afraid to rip it out. tkappinit.c predates the times that Tcl could do dynamic loading. Also, there is no need to operate the same way for all packages; just fix Tix for now. For 2), there are more problems when freezing: In Python 2.1, setup.py will build _tkinter as a dynamic module, and you can't freeze them, anyway. So anybody who wants to freeze would need a build where _tkinter is listed in Modules/Setup. Furthermore, you typically need Tix SAM libraries, or else the binary won't be stand-alone. Then you need static versions of libtcl.a, not shared ones. Anybody who wants to freeze with Tix needs a fair amount of local configuration, so supporting freeze is more complicated. For 3), if Tix does not appear in the C files at all, it can be removed from the .dsp file as well. For setup.py: You still can use Setup if you want to. The problem I see with static linkage that _tkinter then depends on Tix, so to install Python, you'll need to install Tix first; if you build Python not to depend on Tix, you can't use it even when it gets installed. Since most people use binary distributions, they get more out of dynamic loading than they'd get from static linking. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:36 Message: Logged In: YES user_id=33229 I would love to load Tix using package require, because that would be a "good thing", but there are some details: 1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking. My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved. I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach: 1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach. These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored. Don't hesitate to send me email as well idiscovery@users.sourceforge.net Mike. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:17:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:17:26 -0800 Subject: [Patches] [ python-Patches-409045 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409045, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:06 Message: Logged In: YES user_id=21627 There is no need to split your patches into such small pieces. Instead, everything dealing with Tix should be one patch (including changes to Modules/Setup.dist you may want to make). If you want to follow the route of linking Tix statically (which I'd discourage), you should use the same strategy to find the current Tix version as done to find the current Tk version: given the Tk version, iterate over candidate Tix versions and find the most recent one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:17:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:17:26 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 >Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 15:44 Message: Logged In: YES user_id=33229 > I'd rather encourage assigning to > Widget.__bases__ (to get Form into the list of base > classes), instead of putting Tix code into Tkinter. Either way is fine with me. I prefer the more explicit way of showing Tkinter.py readers where the form geometry manager fits in, and I find messing with __foobars__ to be a less visible way of doing magic, but it's up to you. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:53 Message: Logged In: YES user_id=33229 Opps sorry - here's the context diff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:17:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:17:27 -0800 Subject: [Patches] [ python-Patches-409053 ] Add Tix.py to Lib/lib-tk Message-ID: Patches item #409053, was updated on 2001-03-15 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add Tix.py to Lib/lib-tk Initial Comment: At Python9, Guido asked me to contribute Tix into the core. Attached is Tix.py, which should go into Lib/lib-tk It should work for any 2.x, but should have the associated patches I just added apllied as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:47 Message: Logged In: YES user_id=33229 It's safe to add this anyway, even if we use static packages, so go ahead with this change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:20 Message: Logged In: YES user_id=21627 Looks good, it has roughly the same contents that we use as well. To bring up dynamic loading again, we have @@ -69,9 +98,6 @@ self.widgetName = widgetName Widget._setup(self, master, cnf) - # Must load the definitions of all of the Tix commands - self.tk.eval("package require Tix") - # If widgetName is None, this is a dummy creation call where the # corresponding Tk widget has already been created by Tix if widgetName: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:17:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:17:28 -0800 Subject: [Patches] [ python-Patches-409055 ] Tix Demos Message-ID: Patches item #409055, was updated on 2001-03-15 22:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Tix Demos Initial Comment: A tgz of demos for Tix. They should just drop into Demos/tix. The demos are good for any 2.x version, but the documentation is 2.1 specific as it assumes the associated patches I contruibted previous have been applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:17:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:17:30 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 >Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:22:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:22:25 -0800 Subject: [Patches] [ python-Patches-408326 ] slice objects comparable, not hashable Message-ID: Patches item #408326, was updated on 2001-03-13 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Robin Thomas (robin900) >Assigned to: Guido van Rossum (gvanrossum) Summary: slice objects comparable, not hashable Initial Comment: This patch changes the behavior of slice objects in the following manner: - Slice objects are now comparable with other slice objects as though they were logically tuples of (start,stop,step). The tuple is not created in the comparison function, but the comparison behavior is logically equivalent. - Slice objects are not hashable. With the above change to being comparable, slice objects now cannot be used as keys in dictionaries. I ask that this patch be considered a "bug fix", rather than a change in functionality, and thus be included in 2.1b2 and forward. Other proposed changes to slicing and slice objects have been postponed until further discussion and the requisite PEP submission. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 From noreply@sourceforge.net Mon Mar 19 23:21:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 15:21:37 -0800 Subject: [Patches] [ python-Patches-407758 ] timemodule patches for Cygwin Message-ID: Patches item #407758, was updated on 2001-03-11 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407758&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Norman Vine (nhv) >Assigned to: Tim Peters (tim_one) Summary: timemodule patches for Cygwin Initial Comment: Simple patch to fix timezone support on Cygwin ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407758&group_id=5470 From noreply@sourceforge.net Tue Mar 20 00:30:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 16:30:45 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Guido van Rossum (gvanrossum) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-19 16:30 Message: Logged In: YES user_id=33229 I'm happy to load Tix dynamically. Just change the __init__ method of the Tk class to be Tkinter.Tk.__init__(self, screenName, baseName, className) # Load Tix as it is linked dynamically self.tk.eval('package require Tix') and delete the tkinter.TIX_VERSION assignment. Can you email me the incantation to include Form onto Widget.__bases__ ? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 15:44 Message: Logged In: YES user_id=33229 > I'd rather encourage assigning to > Widget.__bases__ (to get Form into the list of base > classes), instead of putting Tix code into Tkinter. Either way is fine with me. I prefer the more explicit way of showing Tkinter.py readers where the form geometry manager fits in, and I find messing with __foobars__ to be a less visible way of doing magic, but it's up to you. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:53 Message: Logged In: YES user_id=33229 Opps sorry - here's the context diff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Tue Mar 20 03:32:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 19:32:01 -0800 Subject: [Patches] [ python-Patches-407758 ] timemodule patches for Cygwin Message-ID: Patches item #407758, was updated on 2001-03-11 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407758&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Norman Vine (nhv) Assigned to: Tim Peters (tim_one) Summary: timemodule patches for Cygwin Initial Comment: Simple patch to fix timezone support on Cygwin ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 19:32 Message: Logged In: YES user_id=31435 Checked in, timemodule.c rev 2.109. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407758&group_id=5470 From noreply@sourceforge.net Tue Mar 20 03:51:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 19:51:05 -0800 Subject: [Patches] [ python-Patches-409924 ] rm configure --with-check-import-case Message-ID: Patches item #409924, was updated on 2001-03-19 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409924&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: rm configure --with-check-import-case Initial Comment: This patch removes the configure --with-check-import-case option that I added in 2.1a1 for Cygwin. This option has been obseleted by Tim Peter's case sensitive import for all platforms patch (PEP 235). To apply: $ # save patch to /tmp/case.patch $ patch Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 04:08:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 20:08:17 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 04:10:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 20:10:19 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 04:11:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 20:11:30 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 04:58:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 20:58:41 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:58 Message: Logged In: YES user_id=31435 @Home is major-league hosed; switching to another ISP to delete 3 of the 4(!) patch copies I managed to attach to this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 05:21:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 21:21:21 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:21 Message: Logged In: YES user_id=31435 Assigned to Guido: since the patch would replace the current future_statement implementation, doing anything with it before Friday would require BDFL decree. I personally like that future_statements don't look like general directives: directive integer_division directive left_hand_side_swap Over time, the set of names grows, and it won't be clear which directives are dead-serious business (like an incompatible language change) and which minor tweaking of pragmatics. An extension was briefly discussed on c.l.py, along the lines of adding another word, e.g. directive future integer_division directive pragma left_hand_side_swap Whatever, AFAIK that didn't get implemented, and there's no PEP for it (or this) in any case (BTW, while I would like to see a PEP for a general directive facility, I'm not going to write one). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:58 Message: Logged In: YES user_id=31435 @Home is major-league hosed; switching to another ISP to delete 3 of the 4(!) patch copies I managed to attach to this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 05:22:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 21:22:41 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Guido van Rossum (gvanrossum) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:22 Message: Logged In: YES user_id=31435 SourceForge is driving me nuts today. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:21 Message: Logged In: YES user_id=31435 Assigned to Guido: since the patch would replace the current future_statement implementation, doing anything with it before Friday would require BDFL decree. I personally like that future_statements don't look like general directives: directive integer_division directive left_hand_side_swap Over time, the set of names grows, and it won't be clear which directives are dead-serious business (like an incompatible language change) and which minor tweaking of pragmatics. An extension was briefly discussed on c.l.py, along the lines of adding another word, e.g. directive future integer_division directive pragma left_hand_side_swap Whatever, AFAIK that didn't get implemented, and there's no PEP for it (or this) in any case (BTW, while I would like to see a PEP for a general directive facility, I'm not going to write one). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:58 Message: Logged In: YES user_id=31435 @Home is major-league hosed; switching to another ISP to delete 3 of the 4(!) patch copies I managed to attach to this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 05:44:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Mar 2001 21:44:03 -0800 Subject: [Patches] [ python-Patches-409924 ] rm configure --with-check-import-case Message-ID: Patches item #409924, was updated on 2001-03-19 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409924&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Guido van Rossum (gvanrossum) Summary: rm configure --with-check-import-case Initial Comment: This patch removes the configure --with-check-import-case option that I added in 2.1a1 for Cygwin. This option has been obseleted by Tim Peter's case sensitive import for all platforms patch (PEP 235). To apply: $ # save patch to /tmp/case.patch $ patch Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:44 Message: Logged In: YES user_id=31435 Guido, care to apply this patch next time you fiddle the Unix config stuff? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409924&group_id=5470 From noreply@sourceforge.net Tue Mar 20 09:57:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 01:57:02 -0800 Subject: [Patches] [ python-Patches-409973 ] glob.glob speedups Message-ID: Patches item #409973, was updated on 2001-03-20 01:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409973&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Rob W.W. Hooft (hooft) Assigned to: Nobody/Anonymous (nobody) Summary: glob.glob speedups Initial Comment: A lot of the time spent by glob.glob on large directories is spent doing os.path.normcase(). Half of this can be saved by normcasing the pattern only once, and on unix the whole normcase call can be left out. This patch attempts to optimize globbing even a bit more by delegating the fnmatching of a list of file names to a new function fnmatch.filter, which allows us to move a few more lookups outside of the file name loop. Furthermore, an optimization is added to glob.glob calls that do not contain any directory specifications, saving a round of os.path.join calls. Speedups of the pattern '*.py?' in the python lib directory range from a factor of 2 with directory specification to a factor of 5 without directory specifications. Unfortunately there is no test_glob regression test, but I did my best to verify that nothing changed in my calls. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409973&group_id=5470 From noreply@sourceforge.net Tue Mar 20 12:15:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 04:15:57 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 04:15 Message: Logged In: YES user_id=21627 Revised patch to match the draft PEP (244?): nested scopes are enabled by "directive transitional nested_scopes", and a warning is produced if "directive" is used as a name. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:22 Message: Logged In: YES user_id=31435 SourceForge is driving me nuts today. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:21 Message: Logged In: YES user_id=31435 Assigned to Guido: since the patch would replace the current future_statement implementation, doing anything with it before Friday would require BDFL decree. I personally like that future_statements don't look like general directives: directive integer_division directive left_hand_side_swap Over time, the set of names grows, and it won't be clear which directives are dead-serious business (like an incompatible language change) and which minor tweaking of pragmatics. An extension was briefly discussed on c.l.py, along the lines of adding another word, e.g. directive future integer_division directive pragma left_hand_side_swap Whatever, AFAIK that didn't get implemented, and there's no PEP for it (or this) in any case (BTW, while I would like to see a PEP for a general directive facility, I'm not going to write one). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:58 Message: Logged In: YES user_id=31435 @Home is major-league hosed; switching to another ISP to delete 3 of the 4(!) patch copies I managed to attach to this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 12:30:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 04:30:39 -0800 Subject: [Patches] [ python-Patches-409043 ] Make _tkinter.c Tix aware Message-ID: Patches item #409043, was updated on 2001-03-15 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Guido van Rossum (gvanrossum) Summary: Make _tkinter.c Tix aware Initial Comment: A small patch to Modules/_tkinter.c to define the constant _tkinter.TIX_VERSION. This will allow Tkinter.py to know if Tix is present, and if do, define the Form geometry manager. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-20 04:30 Message: Logged In: NO Please upload a new file that's not gzipped, and delete obsolete uploaded files. It's hard to know for sure which upload you meant when there are two different files with identical names. Gzipping slows down the review process. (Guido) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 From noreply@sourceforge.net Tue Mar 20 12:42:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 04:42:43 -0800 Subject: [Patches] [ python-Patches-408326 ] slice objects comparable, not hashable Message-ID: Patches item #408326, was updated on 2001-03-13 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Robin Thomas (robin900) Assigned to: Guido van Rossum (gvanrossum) Summary: slice objects comparable, not hashable Initial Comment: This patch changes the behavior of slice objects in the following manner: - Slice objects are now comparable with other slice objects as though they were logically tuples of (start,stop,step). The tuple is not created in the comparison function, but the comparison behavior is logically equivalent. - Slice objects are not hashable. With the above change to being comparable, slice objects now cannot be used as keys in dictionaries. I ask that this patch be considered a "bug fix", rather than a change in functionality, and thus be included in 2.1b2 and forward. Other proposed changes to slicing and slice objects have been postponed until further discussion and the requisite PEP submission. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 04:42 Message: Logged In: YES user_id=6380 Fix applied. Thanks! (Isn't there a corresponding bug report that should be closed?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 From noreply@sourceforge.net Tue Mar 20 12:51:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 04:51:34 -0800 Subject: [Patches] [ python-Patches-409043 ] Make _tkinter.c Tix aware Message-ID: Patches item #409043, was updated on 2001-03-15 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Guido van Rossum (gvanrossum) Summary: Make _tkinter.c Tix aware Initial Comment: A small patch to Modules/_tkinter.c to define the constant _tkinter.TIX_VERSION. This will allow Tkinter.py to know if Tix is present, and if do, define the Form geometry manager. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 04:51 Message: Logged In: YES user_id=6380 Now that I've seen the flurry of patches related to Tix, I prefer to do this after 2.1 is safe and well released. We have 2 days until the code freeze for the 2.1b2 release, and that's too short to make sure this stuff all works correctly. Certainly *I* don't have time to review it at all. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-20 04:30 Message: Logged In: NO Please upload a new file that's not gzipped, and delete obsolete uploaded files. It's hard to know for sure which upload you meant when there are two different files with identical names. Gzipping slows down the review process. (Guido) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 From noreply@sourceforge.net Tue Mar 20 13:09:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 05:09:20 -0800 Subject: [Patches] [ python-Patches-409924 ] rm configure --with-check-import-case Message-ID: Patches item #409924, was updated on 2001-03-19 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409924&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Guido van Rossum (gvanrossum) Summary: rm configure --with-check-import-case Initial Comment: This patch removes the configure --with-check-import-case option that I added in 2.1a1 for Cygwin. This option has been obseleted by Tim Peter's case sensitive import for all platforms patch (PEP 235). To apply: $ # save patch to /tmp/case.patch $ patch Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 05:09 Message: Logged In: YES user_id=6380 Done. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:44 Message: Logged In: YES user_id=31435 Guido, care to apply this patch next time you fiddle the Unix config stuff? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409924&group_id=5470 From noreply@sourceforge.net Tue Mar 20 15:03:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 07:03:34 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches item #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Amos Latteier (amosl) Assigned to: A.M. Kuchling (akuchling) Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-03-20 07:03 Message: Logged In: YES user_id=11375 Here's a different patch, not really derived from Amos's, that writes a PKG-INFO file when generating a source distribution. Still to resolve: * Is there a finalize_options() on the Distribution class where the keywords and platforms values can be converted from strings to lists? * Documentation. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-10 14:25 Message: Logged In: YES user_id=11375 That worked. The patch looks reasonable. There's little point in checking it in at this point, though, until we settle on the metadata fields and decide the XML-vs-other-formats question. ---------------------------------------------------------------------- Comment By: Amos Latteier (amosl) Date: 2001-03-10 13:58 Message: Logged In: YES user_id=157880 I am attempting to upload the patch again. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-10 11:51 Message: Logged In: YES user_id=11375 You seem to have run into the SourceForge file upload bug, because there isn't a patch attached. You may want to try again, or put it on the Web somewhere. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From noreply@sourceforge.net Tue Mar 20 16:09:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 08:09:52 -0800 Subject: [Patches] [ python-Patches-408326 ] slice objects comparable, not hashable Message-ID: Patches item #408326, was updated on 2001-03-13 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 Category: core (C code) Group: None Status: Closed Priority: 5 Submitted By: Robin Thomas (robin900) Assigned to: Guido van Rossum (gvanrossum) Summary: slice objects comparable, not hashable Initial Comment: This patch changes the behavior of slice objects in the following manner: - Slice objects are now comparable with other slice objects as though they were logically tuples of (start,stop,step). The tuple is not created in the comparison function, but the comparison behavior is logically equivalent. - Slice objects are not hashable. With the above change to being comparable, slice objects now cannot be used as keys in dictionaries. I ask that this patch be considered a "bug fix", rather than a change in functionality, and thus be included in 2.1b2 and forward. Other proposed changes to slicing and slice objects have been postponed until further discussion and the requisite PEP submission. ---------------------------------------------------------------------- >Comment By: Robin Thomas (robin900) Date: 2001-03-20 08:09 Message: Logged In: YES user_id=127529 The "bug report" was just a post to the Python list. I'm not aware of a SourceFroge bug issue (although there might be). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 04:42 Message: Logged In: YES user_id=6380 Fix applied. Thanks! (Isn't there a corresponding bug report that should be closed?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408326&group_id=5470 From noreply@sourceforge.net Tue Mar 20 16:26:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 08:26:19 -0800 Subject: [Patches] [ python-Patches-409504 ] Fix freeze: regex, continuation lines Message-ID: Patches item #409504, was updated on 2001-03-18 02:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 Category: demos and tools Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Fix freeze: regex, continuation lines Initial Comment: This patch corrects two bugs in freeze: it won't use freeze anymore, and variables that span over several lines using \-continuation are extracted correctly. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 08:26 Message: Logged In: YES user_id=21627 Since esr has already change regex to re, the patch reduces to error correction, and continuation lines. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 From noreply@sourceforge.net Tue Mar 20 16:27:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 08:27:55 -0800 Subject: [Patches] [ python-Patches-409504 ] Fix freeze: regex, continuation lines Message-ID: Patches item #409504, was updated on 2001-03-18 02:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 Category: demos and tools Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Fix freeze: regex, continuation lines Initial Comment: This patch corrects two bugs in freeze: it won't use freeze anymore, and variables that span over several lines using \-continuation are extracted correctly. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 08:27 Message: Logged In: YES user_id=21627 Remove old patch ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 08:26 Message: Logged In: YES user_id=21627 Since esr has already change regex to re, the patch reduces to error correction, and continuation lines. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 From noreply@sourceforge.net Tue Mar 20 16:32:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 08:32:24 -0800 Subject: [Patches] [ python-Patches-410046 ] asynchat: handle excessive response size Message-ID: Patches item #410046, was updated on 2001-03-20 08:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Doug Fort (dougfort) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat: handle excessive response size Initial Comment: When reading with a numeric terminator, asynchat assumes that if the server didn't send fewer bytes than requested, that it sent exactly the number of bytes requested. This is normally the case, but an overloaded server can return an error message that is larger than the number of bytes requested. When this happens asynchttp.handle_read() goes into a tight loop, returning an empty string for data and zero for a terminator. This patch raises an exception if the number of bytes returned exceeds the number requested. It's kind of an ugly fix, because asynchttp doesn't raise any other exceptions, and passes on those it catches to handle_error. However, this really is an exceptional case, and the results of not handling it are disastrous. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 From noreply@sourceforge.net Tue Mar 20 16:36:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 08:36:38 -0800 Subject: [Patches] [ python-Patches-410046 ] asynchat: handle excessive response size Message-ID: Patches item #410046, was updated on 2001-03-20 08:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Doug Fort (dougfort) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat: handle excessive response size Initial Comment: When reading with a numeric terminator, asynchat assumes that if the server didn't send fewer bytes than requested, that it sent exactly the number of bytes requested. This is normally the case, but an overloaded server can return an error message that is larger than the number of bytes requested. When this happens asynchttp.handle_read() goes into a tight loop, returning an empty string for data and zero for a terminator. This patch raises an exception if the number of bytes returned exceeds the number requested. It's kind of an ugly fix, because asynchttp doesn't raise any other exceptions, and passes on those it catches to handle_error. However, this really is an exceptional case, and the results of not handling it are disastrous. ---------------------------------------------------------------------- >Comment By: Doug Fort (dougfort) Date: 2001-03-20 08:36 Message: Logged In: YES user_id=6399 *** asynchat.pyTue Mar 20 11:11:58 2001 --- asynchat.py.originalTue Mar 20 10:43:01 2001 *************** *** 49,60 **** import socket import asyncore - class async_chat_exception(Exception): - def __init__(self, message): - self._message = message - def __str__(self): - return self._message - class async_chat (asyncore.dispatcher): """This is an abstract class. You must derive from this class, and add the two methods collect_incoming_data() and found_terminator()""" --- 49,54 ---- *************** *** 111,128 **** self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! elif lb == n: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() - else: - # if we got back more than we asked for, the server - # is badly confused - raise async_chat_exception( - "Unexpect response: requested %s bytes got %s. %s" % ( - n, lb, self.ac_in_buffer - )) else: # 3 cases: # 1) end of buffer matches terminator exactly: --- 105,115 ---- self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! else: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: # 3 cases: # 1) end of buffer matches terminator exactly: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 From noreply@sourceforge.net Tue Mar 20 17:20:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 09:20:01 -0800 Subject: [Patches] [ python-Patches-403789 ] Add support to zipfile for passing file-like objects Message-ID: Patches item #403789, was updated on 2001-02-14 04:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403789&group_id=5470 >Category: library Group: None >Status: Open >Priority: 6 Submitted By: Itamar S.T. (itamar) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add support to zipfile for passing file-like objects Initial Comment: zipfile.ZipFile, in its current state, requires the user to pass a filename, which is then opened by ZipFile. I (and probably other people) require the ability to pass a file-like objects to ZipFile instead, e.g. have the zipped data stored in a StringIO object. This patch adds that ability. (Sorry, no unit testing included, and only lightly tested. But the changes are very straightforward.) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-20 09:20 Message: Logged In: YES user_id=3066 Re-opened since the patch has been updated & Itamar reminded me that I was going to look at this. I expect to look at this & others tomorrow. ---------------------------------------------------------------------- Comment By: Itamar S.T. (itamar) Date: 2001-02-20 05:14 Message: As per Yhg1s's suggestion (he won't give me his real name - thomas?), I resubmitted everything as a patch. ---------------------------------------------------------------------- Comment By: Itamar S.T. (itamar) Date: 2001-02-20 04:46 Message: OK, here are some tests (I submitted the whole file, not a patch, since I basically rewrote it.). And I fixed zipfile.py based on your comments. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-19 11:46 Message: Please provide test cases for this. The tests should be added to Lib/test/test_zipfile.py. File-ness should probably be determined by checking if the object is a string or not (remember to test for a Unicode string as well!). Instead of catching an exception from checking for file.name, you can instead fetch the name using getattr(file, 'name', None) and not worry about exceptions; only the AttributeError you were actually trying to catch will be caught, and everything else will "do the right thing" instead of getting masked, as the current code does. I'll re-evaluate the patch when it gets updated at SF. (I think the idea is right -- there's no need to require a built-in file object.) ---------------------------------------------------------------------- Comment By: Itamar S.T. (itamar) Date: 2001-02-14 05:26 Message: Right now I detect file-like objects by doing hasattr(file, "read"). Doing hasattr(file, "write") might be better though, since for mode="w" ZipFiles, all you need are write() and tell() methods on the file-like object. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403789&group_id=5470 From noreply@sourceforge.net Tue Mar 20 20:38:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 12:38:22 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Nobody/Anonymous (nobody) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Tue Mar 20 20:39:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 12:39:01 -0800 Subject: [Patches] [ python-Patches-409043 ] Make _tkinter.c Tix aware Message-ID: Patches item #409043, was updated on 2001-03-15 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Nobody/Anonymous (nobody) Summary: Make _tkinter.c Tix aware Initial Comment: A small patch to Modules/_tkinter.c to define the constant _tkinter.TIX_VERSION. This will allow Tkinter.py to know if Tix is present, and if do, define the Form geometry manager. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 04:51 Message: Logged In: YES user_id=6380 Now that I've seen the flurry of patches related to Tix, I prefer to do this after 2.1 is safe and well released. We have 2 days until the code freeze for the 2.1b2 release, and that's too short to make sure this stuff all works correctly. Certainly *I* don't have time to review it at all. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-20 04:30 Message: Logged In: NO Please upload a new file that's not gzipped, and delete obsolete uploaded files. It's hard to know for sure which upload you meant when there are two different files with identical names. Gzipping slows down the review process. (Guido) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 From noreply@sourceforge.net Tue Mar 20 20:44:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 12:44:55 -0800 Subject: [Patches] [ python-Patches-401702 ] Modify co_filename in frozen programs Message-ID: Patches item #401702, was updated on 2000-09-29 04:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401702&group_id=5470 Category: demos and tools Group: None >Status: Closed >Priority: 5 Submitted By: Lawrence Hudson (lhudson) Assigned to: Guido van Rossum (gvanrossum) Summary: Modify co_filename in frozen programs Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 12:44 Message: Logged In: YES user_id=6380 Applied. Closing now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:02 Message: Logged In: YES user_id=6380 Sure, I see no problem with this patch. I'll see if I can check it in. If someone else who likes to hack freeze would have it, please go ahead! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 23:12 Message: Logged In: YES user_id=6380 Shit. Missed the deadline again. Will try before b2... :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 14:45 Message: No time to review this before the 2.1a1 release; I'll do this for 2.1a2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 07:53 Message: I'm taking this, on the assumption that Mark's too busy and freeze is our shared responsibility. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-01-18 15:57 Message: (somewhat) randomly reassigned; don't have time to look at this ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-25 04:19 Message: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ---------------------------------------------------------------------- Comment By: Lawrence Hudson (lhudson) Date: 2000-10-25 01:36 Message: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\python\lib\") 'c:\python\lib' >>> os.path.normpath("c:\python\Lib\") 'c:\python\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-23 12:33 Message: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-29 07:28 Message: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ---------------------------------------------------------------------- Comment By: Lawrence Hudson (lhudson) Date: 2000-09-29 04:39 Message: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401702&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:01:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:01:55 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-19 10:43 Message: Logged In: YES user_id=21627 For 1), I'd say this is historic garbage (I added some of it myself), so don't be afraid to rip it out. tkappinit.c predates the times that Tcl could do dynamic loading. Also, there is no need to operate the same way for all packages; just fix Tix for now. For 2), there are more problems when freezing: In Python 2.1, setup.py will build _tkinter as a dynamic module, and you can't freeze them, anyway. So anybody who wants to freeze would need a build where _tkinter is listed in Modules/Setup. Furthermore, you typically need Tix SAM libraries, or else the binary won't be stand-alone. Then you need static versions of libtcl.a, not shared ones. Anybody who wants to freeze with Tix needs a fair amount of local configuration, so supporting freeze is more complicated. For 3), if Tix does not appear in the C files at all, it can be removed from the .dsp file as well. For setup.py: You still can use Setup if you want to. The problem I see with static linkage that _tkinter then depends on Tix, so to install Python, you'll need to install Tix first; if you build Python not to depend on Tix, you can't use it even when it gets installed. Since most people use binary distributions, they get more out of dynamic loading than they'd get from static linking. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:36 Message: Logged In: YES user_id=33229 I would love to load Tix using package require, because that would be a "good thing", but there are some details: 1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking. My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved. I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach: 1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach. These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored. Don't hesitate to send me email as well idiscovery@users.sourceforge.net Mike. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:02:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:02:36 -0800 Subject: [Patches] [ python-Patches-409045 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409045, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:06 Message: Logged In: YES user_id=21627 There is no need to split your patches into such small pieces. Instead, everything dealing with Tix should be one patch (including changes to Modules/Setup.dist you may want to make). If you want to follow the route of linking Tix statically (which I'd discourage), you should use the same strategy to find the current Tix version as done to find the current Tk version: given the Tk version, iterate over candidate Tix versions and find the most recent one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:02:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:02:58 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-19 16:30 Message: Logged In: YES user_id=33229 I'm happy to load Tix dynamically. Just change the __init__ method of the Tk class to be Tkinter.Tk.__init__(self, screenName, baseName, className) # Load Tix as it is linked dynamically self.tk.eval('package require Tix') and delete the tkinter.TIX_VERSION assignment. Can you email me the incantation to include Form onto Widget.__bases__ ? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 15:44 Message: Logged In: YES user_id=33229 > I'd rather encourage assigning to > Widget.__bases__ (to get Form into the list of base > classes), instead of putting Tix code into Tkinter. Either way is fine with me. I prefer the more explicit way of showing Tkinter.py readers where the form geometry manager fits in, and I find messing with __foobars__ to be a less visible way of doing magic, but it's up to you. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:53 Message: Logged In: YES user_id=33229 Opps sorry - here's the context diff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:03:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:03:27 -0800 Subject: [Patches] [ python-Patches-409053 ] Add Tix.py to Lib/lib-tk Message-ID: Patches item #409053, was updated on 2001-03-15 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Nobody/Anonymous (nobody) Summary: Add Tix.py to Lib/lib-tk Initial Comment: At Python9, Guido asked me to contribute Tix into the core. Attached is Tix.py, which should go into Lib/lib-tk It should work for any 2.x, but should have the associated patches I just added apllied as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:47 Message: Logged In: YES user_id=33229 It's safe to add this anyway, even if we use static packages, so go ahead with this change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:20 Message: Logged In: YES user_id=21627 Looks good, it has roughly the same contents that we use as well. To bring up dynamic loading again, we have @@ -69,9 +98,6 @@ self.widgetName = widgetName Widget._setup(self, master, cnf) - # Must load the definitions of all of the Tix commands - self.tk.eval("package require Tix") - # If widgetName is None, this is a dummy creation call where the # corresponding Tk widget has already been created by Tix if widgetName: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:04:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:04:04 -0800 Subject: [Patches] [ python-Patches-409055 ] Tix Demos Message-ID: Patches item #409055, was updated on 2001-03-15 22:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Nobody/Anonymous (nobody) Summary: Tix Demos Initial Comment: A tgz of demos for Tix. They should just drop into Demos/tix. The demos are good for any 2.x version, but the documentation is 2.1 specific as it assumes the associated patches I contruibted previous have been applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:05:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:05:51 -0800 Subject: [Patches] [ python-Patches-409504 ] Fix freeze: regex, continuation lines Message-ID: Patches item #409504, was updated on 2001-03-18 02:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 Category: demos and tools Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Fix freeze: regex, continuation lines Initial Comment: This patch corrects two bugs in freeze: it won't use freeze anymore, and variables that span over several lines using \-continuation are extracted correctly. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 13:05 Message: Logged In: YES user_id=6380 Looks good. Martin, please check it in and then close the patch! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 08:27 Message: Logged In: YES user_id=21627 Remove old patch ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 08:26 Message: Logged In: YES user_id=21627 Since esr has already change regex to re, the patch reduces to error correction, and continuation lines. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:08:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:08:56 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open >Priority: 2 Submitted By: Martin v. Löwis (loewis) >Assigned to: Nobody/Anonymous (nobody) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 13:08 Message: Logged In: YES user_id=6380 I'm postponing this now. I like the idea of directives, but I don't think we should disrupt the 2.1 release for this. So let's look at this again after 2.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 04:15 Message: Logged In: YES user_id=21627 Revised patch to match the draft PEP (244?): nested scopes are enabled by "directive transitional nested_scopes", and a warning is produced if "directive" is used as a name. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:22 Message: Logged In: YES user_id=31435 SourceForge is driving me nuts today. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:21 Message: Logged In: YES user_id=31435 Assigned to Guido: since the patch would replace the current future_statement implementation, doing anything with it before Friday would require BDFL decree. I personally like that future_statements don't look like general directives: directive integer_division directive left_hand_side_swap Over time, the set of names grows, and it won't be clear which directives are dead-serious business (like an incompatible language change) and which minor tweaking of pragmatics. An extension was briefly discussed on c.l.py, along the lines of adding another word, e.g. directive future integer_division directive pragma left_hand_side_swap Whatever, AFAIK that didn't get implemented, and there's no PEP for it (or this) in any case (BTW, while I would like to see a PEP for a general directive facility, I'm not going to write one). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:58 Message: Logged In: YES user_id=31435 @Home is major-league hosed; switching to another ISP to delete 3 of the 4(!) patch copies I managed to attach to this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:15:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:15:32 -0800 Subject: [Patches] [ python-Patches-410154 ] Patch for import case-check on macintosh Message-ID: Patches item #410154, was updated on 2001-03-20 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 8 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for import case-check on macintosh Initial Comment: This patch gets filesystem case-checking working again for the Macintosh. I'm submitting it here in stead of checking it in myself because I don't currently have any way to check that this patch doesn't break anything on Unix or Windows. RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.173 diff -c -r2.173 import.c *** import.c 2001/03/06 06:31:15 2.173 --- import.c 2001/03/20 20:59:30 *************** *** 979,991 **** #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) ! fp = fopen(buf, fdp->mode); #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) --- 979,991 ---- #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) { #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); + #endif /* !macintosh */ fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) *************** *** 996,1002 **** } } } - #endif /* !macintosh */ if (fp != NULL) break; } --- 996,1001 ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:25:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:25:12 -0800 Subject: [Patches] [ python-Patches-405228 ] split Telnet class into TelnetBase Message-ID: Patches item #405228, was updated on 2001-03-01 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 Category: library Group: None Status: Open >Priority: 2 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Guido van Rossum (gvanrossum) Summary: split Telnet class into TelnetBase Initial Comment: I've been asked to make telnet, ssh, bash and rpcclient (http://www.samba-tng.org), http requests and possibly much more all look seamlessly like telnet. That means splitting telnetlib.py's Telnet class down into a base class. I need the write, read_until, expect and friends, but did not want to do a total rewrite / total pain-in-the-neck cut/paste job on telnetlib.py just to fulfil the requirements. I have noticed that someone wrote an scp class, already before: it's available on parnassus. it wraps scp in popen. with this TelnetBase class, doing the same thing will be trivial _and_ you get the exact same look and functionality as if it was a Telnet() instance. well, it makes _me_ happy enough to submit this patch. copyright is hereby assigned to Guido van Rossum. authorship must remain as-is. have fun, luke ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 18:23 Message: Logged In: YES user_id=6380 This version of the patch looks like it needs a lot of work. Sent comments directly to author. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 18:47 Message: Logged In: YES user_id=6380 I'll try to do this after b1 is released. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-03-01 11:32 Message: Logged In: YES user_id=80200 good grief. what the hell is wrong with sourceforge??? you can't upload files! grrr. diff -u will be sent to patches@python.org. grrr ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:34:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:34:08 -0800 Subject: [Patches] [ python-Patches-409307 ] Create parsermodule.h Message-ID: Patches item #409307, was updated on 2001-03-16 19:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409307&group_id=5470 Category: Modules Group: None Status: Open Priority: 7 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (this is my second try...if it comes through twice, close one of them!) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The attached patch describes the changes to parsermodule.c. Here's what should be in include/parsermodule.h #ifndef Py_PARSEROBJECT_H #define Py_PARSEROBJECT_H #ifdef __cplusplus extern "C" { #endif /* There are two types of intermediate objects we're interested in: * 'eval' and 'exec' types. These constants can be used in the ast_type * field of the object type to identify which any given object represents. * * The PyAST_FRAGMENT type is not currently supported. Maybe not useful? * Haven't decided yet. */ #define PyAST_EXPR 1 #define PyAST_SUITE 2 #define PyAST_FRAGMENT 3 typedef struct _PyAST_Object { PyObject_HEAD /* standard object header */ node* ast_node; /* the node* returned by the parser */ int ast_type; /* EXPR or SUITE ? */ } PyAST_Object; extern DL_IMPORT(PyObject *) parser_newastobject(node *ast, int type); #ifdef __cplusplus } #endif #endif /* !Py_PARSEROBJECT_H */ ---------------------------------------------------------------------- >Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:34 Message: Logged In: YES user_id=31788 I've updated the patch. I'm also going to update the header so you can ignore the one above. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409307&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:38:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:38:36 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was updated on 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:39:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:39:53 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was updated on 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- >Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:39 Message: Logged In: YES user_id=31788 I'm adding the changes to parsermodule.c that need to be made so as not to duplicate the information in the new parsermodule.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:41:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:41:19 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was updated on 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- >Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:41 Message: Logged In: YES user_id=31788 (argh...the patch didn't show up) ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:39 Message: Logged In: YES user_id=31788 I'm adding the changes to parsermodule.c that need to be made so as not to duplicate the information in the new parsermodule.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From noreply@sourceforge.net Tue Mar 20 21:43:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 13:43:03 -0800 Subject: [Patches] [ python-Patches-409307 ] Create parsermodule.h Message-ID: Patches item #409307, was updated on 2001-03-16 19:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409307&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 7 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (this is my second try...if it comes through twice, close one of them!) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The attached patch describes the changes to parsermodule.c. Here's what should be in include/parsermodule.h #ifndef Py_PARSEROBJECT_H #define Py_PARSEROBJECT_H #ifdef __cplusplus extern "C" { #endif /* There are two types of intermediate objects we're interested in: * 'eval' and 'exec' types. These constants can be used in the ast_type * field of the object type to identify which any given object represents. * * The PyAST_FRAGMENT type is not currently supported. Maybe not useful? * Haven't decided yet. */ #define PyAST_EXPR 1 #define PyAST_SUITE 2 #define PyAST_FRAGMENT 3 typedef struct _PyAST_Object { PyObject_HEAD /* standard object header */ node* ast_node; /* the node* returned by the parser */ int ast_type; /* EXPR or SUITE ? */ } PyAST_Object; extern DL_IMPORT(PyObject *) parser_newastobject(node *ast, int type); #ifdef __cplusplus } #endif #endif /* !Py_PARSEROBJECT_H */ ---------------------------------------------------------------------- >Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:43 Message: Logged In: YES user_id=31788 Superceded by 410161 ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:34 Message: Logged In: YES user_id=31788 I've updated the patch. I'm also going to update the header so you can ignore the one above. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409307&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:16:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:16:47 -0800 Subject: [Patches] [ python-Patches-405792 ] Run configure instead of config.status Message-ID: Patches item #405792, was updated on 2001-03-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Run configure instead of config.status Initial Comment: The config.status script does not check configure's exit status. This causes an infinite loop if configure is newer than config.status and configure fails for some reason. One way to test this is to first run configure and then add an "exit 1" line at the top of configure. Running make will cause an infinite loop. I think its best to avoid using config.status all together. Its easy to save the configure arguments. Assigned to Guido since it looks like he originally add the WITH variable. Will anyone care if we get rid of it? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:16 Message: Logged In: YES user_id=6380 Neil, can you propose a patch? I'm not quite clear what you are proposing here -- a patch would be most clarifying! Assign back to me with patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:39:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:39:50 -0800 Subject: [Patches] [ python-Patches-409043 ] Make _tkinter.c Tix aware Message-ID: Patches item #409043, was updated on 2001-03-15 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 Category: Tkinter Group: None Status: Open >Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Make _tkinter.c Tix aware Initial Comment: A small patch to Modules/_tkinter.c to define the constant _tkinter.TIX_VERSION. This will allow Tkinter.py to know if Tix is present, and if do, define the Form geometry manager. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 04:51 Message: Logged In: YES user_id=6380 Now that I've seen the flurry of patches related to Tix, I prefer to do this after 2.1 is safe and well released. We have 2 days until the code freeze for the 2.1b2 release, and that's too short to make sure this stuff all works correctly. Certainly *I* don't have time to review it at all. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-20 04:30 Message: Logged In: NO Please upload a new file that's not gzipped, and delete obsolete uploaded files. It's hard to know for sure which upload you meant when there are two different files with identical names. Gzipping slows down the review process. (Guido) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:39:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:39:51 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open >Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-19 10:43 Message: Logged In: YES user_id=21627 For 1), I'd say this is historic garbage (I added some of it myself), so don't be afraid to rip it out. tkappinit.c predates the times that Tcl could do dynamic loading. Also, there is no need to operate the same way for all packages; just fix Tix for now. For 2), there are more problems when freezing: In Python 2.1, setup.py will build _tkinter as a dynamic module, and you can't freeze them, anyway. So anybody who wants to freeze would need a build where _tkinter is listed in Modules/Setup. Furthermore, you typically need Tix SAM libraries, or else the binary won't be stand-alone. Then you need static versions of libtcl.a, not shared ones. Anybody who wants to freeze with Tix needs a fair amount of local configuration, so supporting freeze is more complicated. For 3), if Tix does not appear in the C files at all, it can be removed from the .dsp file as well. For setup.py: You still can use Setup if you want to. The problem I see with static linkage that _tkinter then depends on Tix, so to install Python, you'll need to install Tix first; if you build Python not to depend on Tix, you can't use it even when it gets installed. Since most people use binary distributions, they get more out of dynamic loading than they'd get from static linking. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:36 Message: Logged In: YES user_id=33229 I would love to load Tix using package require, because that would be a "good thing", but there are some details: 1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking. My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved. I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach: 1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach. These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored. Don't hesitate to send me email as well idiscovery@users.sourceforge.net Mike. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:39:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:39:51 -0800 Subject: [Patches] [ python-Patches-409045 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409045, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 Category: Tkinter Group: None Status: Open >Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:06 Message: Logged In: YES user_id=21627 There is no need to split your patches into such small pieces. Instead, everything dealing with Tix should be one patch (including changes to Modules/Setup.dist you may want to make). If you want to follow the route of linking Tix statically (which I'd discourage), you should use the same strategy to find the current Tix version as done to find the current Tk version: given the Tk version, iterate over candidate Tix versions and find the most recent one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:39:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:39:51 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: Tkinter Group: None Status: Open >Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-19 16:30 Message: Logged In: YES user_id=33229 I'm happy to load Tix dynamically. Just change the __init__ method of the Tk class to be Tkinter.Tk.__init__(self, screenName, baseName, className) # Load Tix as it is linked dynamically self.tk.eval('package require Tix') and delete the tkinter.TIX_VERSION assignment. Can you email me the incantation to include Form onto Widget.__bases__ ? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 15:44 Message: Logged In: YES user_id=33229 > I'd rather encourage assigning to > Widget.__bases__ (to get Form into the list of base > classes), instead of putting Tix code into Tkinter. Either way is fine with me. I prefer the more explicit way of showing Tkinter.py readers where the form geometry manager fits in, and I find messing with __foobars__ to be a less visible way of doing magic, but it's up to you. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:53 Message: Logged In: YES user_id=33229 Opps sorry - here's the context diff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:39:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:39:52 -0800 Subject: [Patches] [ python-Patches-409053 ] Add Tix.py to Lib/lib-tk Message-ID: Patches item #409053, was updated on 2001-03-15 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 Category: Tkinter Group: None Status: Open >Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Add Tix.py to Lib/lib-tk Initial Comment: At Python9, Guido asked me to contribute Tix into the core. Attached is Tix.py, which should go into Lib/lib-tk It should work for any 2.x, but should have the associated patches I just added apllied as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:47 Message: Logged In: YES user_id=33229 It's safe to add this anyway, even if we use static packages, so go ahead with this change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:20 Message: Logged In: YES user_id=21627 Looks good, it has roughly the same contents that we use as well. To bring up dynamic loading again, we have @@ -69,9 +98,6 @@ self.widgetName = widgetName Widget._setup(self, master, cnf) - # Must load the definitions of all of the Tix commands - self.tk.eval("package require Tix") - # If widgetName is None, this is a dummy creation call where the # corresponding Tk widget has already been created by Tix if widgetName: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:39:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:39:53 -0800 Subject: [Patches] [ python-Patches-409055 ] Tix Demos Message-ID: Patches item #409055, was updated on 2001-03-15 22:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 Category: Tkinter Group: None Status: Open >Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Demos Initial Comment: A tgz of demos for Tix. They should just drop into Demos/tix. The demos are good for any 2.x version, but the documentation is 2.1 specific as it assumes the associated patches I contruibted previous have been applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:39:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:39:54 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Tkinter Group: None Status: Open >Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Tue Mar 20 22:54:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 14:54:39 -0800 Subject: [Patches] [ python-Patches-410154 ] Patch for import case-check on macintosh Message-ID: Patches item #410154, was updated on 2001-03-20 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 8 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: Patch for import case-check on macintosh Initial Comment: This patch gets filesystem case-checking working again for the Macintosh. I'm submitting it here in stead of checking it in myself because I don't currently have any way to check that this patch doesn't break anything on Unix or Windows. RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.173 diff -c -r2.173 import.c *** import.c 2001/03/06 06:31:15 2.173 --- import.c 2001/03/20 20:59:30 *************** *** 979,991 **** #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) ! fp = fopen(buf, fdp->mode); #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) --- 979,991 ---- #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) { #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); + #endif /* !macintosh */ fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) *************** *** 996,1002 **** } } } - #endif /* !macintosh */ if (fp != NULL) break; } --- 996,1001 ---- ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:54 Message: Logged In: YES user_id=6380 Jack, this compiles and builds fine on Linux. So please go ahead! (Please next time use the SourceForge file upload feature -- SF doesn't treat whitespace properly!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 From noreply@sourceforge.net Wed Mar 21 02:30:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 18:30:19 -0800 Subject: [Patches] [ python-Patches-410154 ] Patch for import case-check on macintosh Message-ID: Patches item #410154, was updated on 2001-03-20 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 8 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Patch for import case-check on macintosh Initial Comment: This patch gets filesystem case-checking working again for the Macintosh. I'm submitting it here in stead of checking it in myself because I don't currently have any way to check that this patch doesn't break anything on Unix or Windows. RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.173 diff -c -r2.173 import.c *** import.c 2001/03/06 06:31:15 2.173 --- import.c 2001/03/20 20:59:30 *************** *** 979,991 **** #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) ! fp = fopen(buf, fdp->mode); #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) --- 979,991 ---- #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) { #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); + #endif /* !macintosh */ fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) *************** *** 996,1002 **** } } } - #endif /* !macintosh */ if (fp != NULL) break; } --- 996,1001 ---- ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-20 18:30 Message: Logged In: YES user_id=31435 Jack, it looks to me like you checked in this in. In that case you should change the Status to Closed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:54 Message: Logged In: YES user_id=6380 Jack, this compiles and builds fine on Linux. So please go ahead! (Please next time use the SourceForge file upload feature -- SF doesn't treat whitespace properly!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 From noreply@sourceforge.net Wed Mar 21 02:52:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 18:52:06 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches item #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Amos Latteier (amosl) Assigned to: A.M. Kuchling (akuchling) Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-03-20 18:52 Message: Logged In: YES user_id=11375 Final version, and believed ready to check in. write_pkg_info() is now a method on the DistributionMetadata class as suggested by Amos, and a finalize_options() method has been added to Distribution. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-20 07:03 Message: Logged In: YES user_id=11375 Here's a different patch, not really derived from Amos's, that writes a PKG-INFO file when generating a source distribution. Still to resolve: * Is there a finalize_options() on the Distribution class where the keywords and platforms values can be converted from strings to lists? * Documentation. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-10 14:25 Message: Logged In: YES user_id=11375 That worked. The patch looks reasonable. There's little point in checking it in at this point, though, until we settle on the metadata fields and decide the XML-vs-other-formats question. ---------------------------------------------------------------------- Comment By: Amos Latteier (amosl) Date: 2001-03-10 13:58 Message: Logged In: YES user_id=157880 I am attempting to upload the patch again. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-10 11:51 Message: Logged In: YES user_id=11375 You seem to have run into the SourceForge file upload bug, because there isn't a patch attached. You may want to try again, or put it on the Web somewhere. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From noreply@sourceforge.net Wed Mar 21 03:32:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 19:32:43 -0800 Subject: [Patches] [ python-Patches-410223 ] Replaces and Replaced-By PEP headers Message-ID: Patches item #410223, was updated on 2001-03-20 19:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410223&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Barry Warsaw (bwarsaw) Summary: Replaces and Replaced-By PEP headers Initial Comment: The attached patch adds text to PEP 1 describing the Replaced-By and Replaces headers, and patches pep2html.py to hyperlink those headers properly. Barry, feel free to rewrite/modify and check in at your leisure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410223&group_id=5470 From noreply@sourceforge.net Wed Mar 21 04:50:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 20:50:36 -0800 Subject: [Patches] [ python-Patches-405792 ] Run configure instead of config.status Message-ID: Patches item #405792, was updated on 2001-03-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Run configure instead of config.status Initial Comment: The config.status script does not check configure's exit status. This causes an infinite loop if configure is newer than config.status and configure fails for some reason. One way to test this is to first run configure and then add an "exit 1" line at the top of configure. Running make will cause an infinite loop. I think its best to avoid using config.status all together. Its easy to save the configure arguments. Assigned to Guido since it looks like he originally add the WITH variable. Will anyone care if we get rid of it? ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:50 Message: Logged In: YES user_id=35752 Please Mr SF, let me upload a patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:16 Message: Logged In: YES user_id=6380 Neil, can you propose a patch? I'm not quite clear what you are proposing here -- a patch would be most clarifying! Assign back to me with patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 From noreply@sourceforge.net Wed Mar 21 04:53:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 20:53:08 -0800 Subject: [Patches] [ python-Patches-405792 ] Run configure instead of config.status Message-ID: Patches item #405792, was updated on 2001-03-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: Run configure instead of config.status Initial Comment: The config.status script does not check configure's exit status. This causes an infinite loop if configure is newer than config.status and configure fails for some reason. One way to test this is to first run configure and then add an "exit 1" line at the top of configure. Running make will cause an infinite loop. I think its best to avoid using config.status all together. Its easy to save the configure arguments. Assigned to Guido since it looks like he originally add the WITH variable. Will anyone care if we get rid of it? ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:53 Message: Logged In: YES user_id=35752 Yah! Guido, please take a look. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:50 Message: Logged In: YES user_id=35752 Please Mr SF, let me upload a patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:16 Message: Logged In: YES user_id=6380 Neil, can you propose a patch? I'm not quite clear what you are proposing here -- a patch would be most clarifying! Assign back to me with patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:02:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:02:33 -0800 Subject: [Patches] [ python-Patches-410231 ] make setup.py do dynamic Tk extensions Message-ID: Patches item #410231, was updated on 2001-03-20 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410231&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: make setup.py do dynamic Tk extensions Initial Comment: In patch [#409043] Make _tkinter.c Tix aware, Guido wrote Now that I've seen the flurry of patches related to Tix, I prefer to do this after 2.1 is safe and well released. We have 2 days until the code freeze for the 2.1b2 release, and that's too short to make sure this stuff all works correctly. Certainly *I* don't have time to review it at all. Sorry for the flurry, but it helped me seperate the different issues with Martin Loewis's comments. He argued that Tix, and all Tk extensions, should be loaded dynamically, using tcl's [package require]. I agree, and this is fundamentally consistent with the approach of setup.py. I have unpdated Tix.py accordingly, and it is now standalone and dynamic. The problem is that setup.py is not internally consistent, because even when it is building Tcl/Tk dynamically, it then tries to add WITH_* to build the extensions *statically*. It may be *vital* to have Tix included in 2.1b2 to act as a testbed for building Tk extensions dynamically. With setup.py you're trying to build dynamically, but with Modules/Setup you're trying to build statically, and Tools/freeze *requires* static build, etc. There are a number of areas where the documentation (/README /Tools/freeze/README) and code comments (Modules/Setup, tclappinit.c, _tkinter.c, Tools/freeze/freeze.py) need improving to explain static vs. dynamic issues, and having Tix in 2.1b2 will help flush these issues out. I'll close out the flurry of other patches - this file replaces them all. You may have to delete the files associated with my other patches as I don't have permission. No matter what *please* update all tix4.1.8.0 to tix8.1.8.2 in 2.0.1 and 2.1 as tix4.1.8.0 was never an official release, and most Linux releases are now distributing tix8.1.8.x. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410231&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:05:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:05:52 -0800 Subject: [Patches] [ python-Patches-409048 ] Form geometry manager for Tkinter.py Message-ID: Patches item #409048, was updated on 2001-03-15 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 Category: Tkinter Group: None >Status: Deleted Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Form geometry manager for Tkinter.py Initial Comment: If you accept patch #409043 which defines the constant _tkinter.TIX_VERSION, then you will no longer need to patch Lib/lib-tk/Tkinter.py to use Tix. With this patch, Tkinter.py will look for _tkinter.TIX_VERSION, and iff it finds it, will add the Form geometry manager to all Tkinter widgets. If not, the current behaviour is maintained. The context diff is against 2.1b1, but should work for 2.0 as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-19 16:30 Message: Logged In: YES user_id=33229 I'm happy to load Tix dynamically. Just change the __init__ method of the Tk class to be Tkinter.Tk.__init__(self, screenName, baseName, className) # Load Tix as it is linked dynamically self.tk.eval('package require Tix') and delete the tkinter.TIX_VERSION assignment. Can you email me the incantation to include Form onto Widget.__bases__ ? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 15:44 Message: Logged In: YES user_id=33229 > I'd rather encourage assigning to > Widget.__bases__ (to get Form into the list of base > classes), instead of putting Tix code into Tkinter. Either way is fine with me. I prefer the more explicit way of showing Tkinter.py readers where the form geometry manager fits in, and I find messing with __foobars__ to be a less visible way of doing magic, but it's up to you. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:53 Message: Logged In: YES user_id=33229 Opps sorry - here's the context diff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:13 Message: Logged In: YES user_id=21627 It turns out that the context diff is not a diff at all, but the full file; please resubmit. However, I'd rather see a solution that has Tix as a stand-alone module. If you think you need the Form methods on every widget, I'd rather encourage assigning to Widget.__bases__ (to get Form into the list of base classes), instead of putting Tix code into Tkinter. If that is not acceptable, I still favour loading Tix dynamically; Tkinter.py would then be the place where that happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409048&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:06:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:06:23 -0800 Subject: [Patches] [ python-Patches-409045 ] Update tcl/tk/tix versions (2) Message-ID: Patches item #409045, was updated on 2001-03-15 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 Category: Tkinter Group: None >Status: Deleted Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions (2) Initial Comment: A small patch to setup.py to update the Tix version to the current tix8.1.8.2 library. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:06 Message: Logged In: YES user_id=21627 There is no need to split your patches into such small pieces. Instead, everything dealing with Tix should be one patch (including changes to Modules/Setup.dist you may want to make). If you want to follow the route of linking Tix statically (which I'd discourage), you should use the same strategy to find the current Tix version as done to find the current Tk version: given the Tk version, iterate over candidate Tix versions and find the most recent one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409045&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:07:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:07:40 -0800 Subject: [Patches] [ python-Patches-409043 ] Make _tkinter.c Tix aware Message-ID: Patches item #409043, was updated on 2001-03-15 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 Category: Tkinter Group: None >Status: Deleted Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Make _tkinter.c Tix aware Initial Comment: A small patch to Modules/_tkinter.c to define the constant _tkinter.TIX_VERSION. This will allow Tkinter.py to know if Tix is present, and if do, define the Form geometry manager. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 04:51 Message: Logged In: YES user_id=6380 Now that I've seen the flurry of patches related to Tix, I prefer to do this after 2.1 is safe and well released. We have 2 days until the code freeze for the 2.1b2 release, and that's too short to make sure this stuff all works correctly. Certainly *I* don't have time to review it at all. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-20 04:30 Message: Logged In: NO Please upload a new file that's not gzipped, and delete obsolete uploaded files. It's hard to know for sure which upload you meant when there are two different files with identical names. Gzipping slows down the review process. (Guido) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409043&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:08:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:08:52 -0800 Subject: [Patches] [ python-Patches-409053 ] Add Tix.py to Lib/lib-tk Message-ID: Patches item #409053, was updated on 2001-03-15 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 Category: Tkinter Group: None >Status: Deleted Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Add Tix.py to Lib/lib-tk Initial Comment: At Python9, Guido asked me to contribute Tix into the core. Attached is Tix.py, which should go into Lib/lib-tk It should work for any 2.x, but should have the associated patches I just added apllied as well. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:47 Message: Logged In: YES user_id=33229 It's safe to add this anyway, even if we use static packages, so go ahead with this change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:20 Message: Logged In: YES user_id=21627 Looks good, it has roughly the same contents that we use as well. To bring up dynamic loading again, we have @@ -69,9 +98,6 @@ self.widgetName = widgetName Widget._setup(self, master, cnf) - # Must load the definitions of all of the Tix commands - self.tk.eval("package require Tix") - # If widgetName is None, this is a dummy creation call where the # corresponding Tk widget has already been created by Tix if widgetName: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409053&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:18:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:18:40 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:18 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid for all Tk extensions, even for 2.0.x, as the -L must proceed *any* -l. Also, tix4.1.8.0 was never an official release, and most Linux releases are now distributing tix8.1.8.x. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-19 10:43 Message: Logged In: YES user_id=21627 For 1), I'd say this is historic garbage (I added some of it myself), so don't be afraid to rip it out. tkappinit.c predates the times that Tcl could do dynamic loading. Also, there is no need to operate the same way for all packages; just fix Tix for now. For 2), there are more problems when freezing: In Python 2.1, setup.py will build _tkinter as a dynamic module, and you can't freeze them, anyway. So anybody who wants to freeze would need a build where _tkinter is listed in Modules/Setup. Furthermore, you typically need Tix SAM libraries, or else the binary won't be stand-alone. Then you need static versions of libtcl.a, not shared ones. Anybody who wants to freeze with Tix needs a fair amount of local configuration, so supporting freeze is more complicated. For 3), if Tix does not appear in the C files at all, it can be removed from the .dsp file as well. For setup.py: You still can use Setup if you want to. The problem I see with static linkage that _tkinter then depends on Tix, so to install Python, you'll need to install Tix first; if you build Python not to depend on Tix, you can't use it even when it gets installed. Since most people use binary distributions, they get more out of dynamic loading than they'd get from static linking. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:36 Message: Logged In: YES user_id=33229 I would love to load Tix using package require, because that would be a "good thing", but there are some details: 1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking. My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved. I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach: 1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach. These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored. Don't hesitate to send me email as well idiscovery@users.sourceforge.net Mike. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:20:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:20:54 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Tkinter Group: None Status: Open Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Wed Mar 21 05:21:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 21:21:45 -0800 Subject: [Patches] [ python-Patches-409055 ] Tix Demos Message-ID: Patches item #409055, was updated on 2001-03-15 22:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 Category: Tkinter Group: None >Status: Deleted Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Demos Initial Comment: A tgz of demos for Tix. They should just drop into Demos/tix. The demos are good for any 2.x version, but the documentation is 2.1 specific as it assumes the associated patches I contruibted previous have been applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409055&group_id=5470 From noreply@sourceforge.net Wed Mar 21 06:02:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 22:02:32 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Jeremy Hylton (jhylton) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Wed Mar 21 06:05:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 22:05:17 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) >Assigned to: Guido van Rossum (gvanrossum) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:57 Message: Logged In: YES user_id=6380 Ping, I was testing this in a loop looking for leaks (none found BTW) and I noticed that it couldn't be killed by control-C. Can you see a reason why? Also, I was looking at the Python code in traceback.py and it has a limit on how many frames it prints (which defaults to sys.tracebacklimit). Would it make sense to be able to pass that into sys.excepthook() as well? Note; I'm seeing enough little questions that make me think this is best left until after 2.1 is released... Would you be very disappointed? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-18 15:33 Message: Logged In: NO PS-- I would suggest to store a copy in sys.__excepthook__, just like sys.__stdout__. Guido (too lazy to log in on SF) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:10 Message: Logged In: YES user_id=6380 Very close. Thanks, Ping! Mandatory improvement:most of the times where you use fprintf(stderr, ...) you should be using PySys_WriteStderr(...). The only time when it's OK to use stderr directly is is when sys.stderr is not found. An idea which I'm not sure of: maybe the PyErr_Display() function could take a PyObject * 4th argument being the file object to which the traceback should be written. This makes the logic of its callers a bit more convoluted, unless you let it default to NULL (which might be the best thing anyway). Also... I guess we need a few lines of documentation for sys.excepthook, for PyErr_Display(), and for the changed semantics of PyErr_Print[Ex](). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Wed Mar 21 06:05:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 22:05:57 -0800 Subject: [Patches] [ python-Patches-407093 ] urllib2 correction of typos Message-ID: Patches item #407093, was updated on 2001-03-08 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407093&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Eduardo Fernandez Corrales (ejfc) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 correction of typos Initial Comment: Bug #406683 "typos in urllib2" includes a patch. I have modified it so that Basic HTTP Authentication works now. (At least with my Squid proxy) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407093&group_id=5470 From noreply@sourceforge.net Wed Mar 21 06:17:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 22:17:41 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was updated on 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-20 22:17 Message: Logged In: YES user_id=3066 I'll try to check in something similar tomorrow, when I've had a little time to sit on this now that I've actually read the comments. ;-) I don't think the included header is exactly right, but that's in part that I don't think the names are good (yes, I know they're mine!). ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:41 Message: Logged In: YES user_id=31788 (argh...the patch didn't show up) ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:39 Message: Logged In: YES user_id=31788 I'm adding the changes to parsermodule.c that need to be made so as not to duplicate the information in the new parsermodule.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From noreply@sourceforge.net Wed Mar 21 07:00:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 23:00:12 -0800 Subject: [Patches] [ python-Patches-409504 ] Fix freeze: regex, continuation lines Message-ID: Patches item #409504, was updated on 2001-03-18 02:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 Category: demos and tools Group: None >Status: Closed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Fix freeze: regex, continuation lines Initial Comment: This patch corrects two bugs in freeze: it won't use freeze anymore, and variables that span over several lines using \-continuation are extracted correctly. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 23:00 Message: Logged In: YES user_id=21627 Committed as 1.5 of makeconfig.py and 1.3 ofparsesetup.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 13:05 Message: Logged In: YES user_id=6380 Looks good. Martin, please check it in and then close the patch! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 08:27 Message: Logged In: YES user_id=21627 Remove old patch ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 08:26 Message: Logged In: YES user_id=21627 Since esr has already change regex to re, the patch reduces to error correction, and continuation lines. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409504&group_id=5470 From noreply@sourceforge.net Wed Mar 21 07:54:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Mar 2001 23:54:09 -0800 Subject: [Patches] [ python-Patches-410231 ] make setup.py do dynamic Tk extensions Message-ID: Patches item #410231, was updated on 2001-03-20 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410231&group_id=5470 Category: Tkinter Group: None >Status: Closed Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: make setup.py do dynamic Tk extensions Initial Comment: In patch [#409043] Make _tkinter.c Tix aware, Guido wrote Now that I've seen the flurry of patches related to Tix, I prefer to do this after 2.1 is safe and well released. We have 2 days until the code freeze for the 2.1b2 release, and that's too short to make sure this stuff all works correctly. Certainly *I* don't have time to review it at all. Sorry for the flurry, but it helped me seperate the different issues with Martin Loewis's comments. He argued that Tix, and all Tk extensions, should be loaded dynamically, using tcl's [package require]. I agree, and this is fundamentally consistent with the approach of setup.py. I have unpdated Tix.py accordingly, and it is now standalone and dynamic. The problem is that setup.py is not internally consistent, because even when it is building Tcl/Tk dynamically, it then tries to add WITH_* to build the extensions *statically*. It may be *vital* to have Tix included in 2.1b2 to act as a testbed for building Tk extensions dynamically. With setup.py you're trying to build dynamically, but with Modules/Setup you're trying to build statically, and Tools/freeze *requires* static build, etc. There are a number of areas where the documentation (/README /Tools/freeze/README) and code comments (Modules/Setup, tclappinit.c, _tkinter.c, Tools/freeze/freeze.py) need improving to explain static vs. dynamic issues, and having Tix in 2.1b2 will help flush these issues out. I'll close out the flurry of other patches - this file replaces them all. You may have to delete the files associated with my other patches as I don't have permission. No matter what *please* update all tix4.1.8.0 to tix8.1.8.2 in 2.0.1 and 2.1 as tix4.1.8.0 was never an official release, and most Linux releases are now distributing tix8.1.8.x. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 23:54 Message: Logged In: YES user_id=21627 Thanks for your efforts. I have applied most of the patch: Tix.py, Demo/tix, and a modified version of the setup.py part. I have not changed Modules/Setup.dist: This file has to be manually adjusted, and your adjustment will be incorrect on other systems. BTW, 4.1.8.0 has not been released less than 8.1.8.2 has: Tix 4.1 *has* been released, and 4.1.8.0 is what you get when you install Tix 4.1 on top of Tk 8.0. It is also what SuSE 7.0 distributes; Mandrake 7.2 ships libtix4.1.8.3. I have also not committed the documentation; that is for Fred Drake to decide. I personally find it way to short to be useful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410231&group_id=5470 From noreply@sourceforge.net Wed Mar 21 09:25:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 01:25:47 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 >Category: documentation Group: None Status: Open Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Wed Mar 21 09:43:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 01:43:43 -0800 Subject: [Patches] [ python-Patches-410267 ] some additional constants for termios Message-ID: Patches item #410267, was updated on 2001-03-21 01:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: some additional constants for termios Initial Comment: This adds a pile of constants that were in my old plat-linux2/TERMIOS.py that aren't in the new termios.c. I'm not sure all of them have valid uses, but some of them certainly do (I noticed that TIOCGWINSZ was missing). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 From noreply@sourceforge.net Wed Mar 21 10:02:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 02:02:53 -0800 Subject: [Patches] [ python-Patches-410154 ] Patch for import case-check on macintosh Message-ID: Patches item #410154, was updated on 2001-03-20 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 8 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Patch for import case-check on macintosh Initial Comment: This patch gets filesystem case-checking working again for the Macintosh. I'm submitting it here in stead of checking it in myself because I don't currently have any way to check that this patch doesn't break anything on Unix or Windows. RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.173 diff -c -r2.173 import.c *** import.c 2001/03/06 06:31:15 2.173 --- import.c 2001/03/20 20:59:30 *************** *** 979,991 **** #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) ! fp = fopen(buf, fdp->mode); #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) --- 979,991 ---- #endif #ifdef macintosh fdp = PyMac_FindModuleExtension(buf, &len, name); ! if (fdp) { #else for (fdp = _PyImport_Filetab; fdp->suffix != NULL; fdp++) { strcpy(buf+len, fdp->suffix); if (Py_VerboseFlag > 1) PySys_WriteStderr("# trying %s\n", buf); + #endif /* !macintosh */ fp = fopen(buf, fdp->mode); if (fp != NULL) { if (case_ok(buf, len, namelen, name)) *************** *** 996,1002 **** } } } - #endif /* !macintosh */ if (fp != NULL) break; } --- 996,1001 ---- ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-03-21 02:02 Message: Logged In: YES user_id=45365 Ok, closed it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-20 18:30 Message: Logged In: YES user_id=31435 Jack, it looks to me like you checked in this in. In that case you should change the Status to Closed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:54 Message: Logged In: YES user_id=6380 Jack, this compiles and builds fine on Linux. So please go ahead! (Please next time use the SourceForge file upload feature -- SF doesn't treat whitespace properly!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410154&group_id=5470 From noreply@sourceforge.net Wed Mar 21 16:05:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 08:05:09 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Wed Mar 21 16:07:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 08:07:24 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Wed Mar 21 16:11:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 08:11:34 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Wed Mar 21 16:17:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 08:17:24 -0800 Subject: [Patches] [ python-Patches-410267 ] some additional constants for termios Message-ID: Patches item #410267, was updated on 2001-03-21 01:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: some additional constants for termios Initial Comment: This adds a pile of constants that were in my old plat-linux2/TERMIOS.py that aren't in the new termios.c. I'm not sure all of them have valid uses, but some of them certainly do (I noticed that TIOCGWINSZ was missing). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:17 Message: Logged In: YES user_id=6656 CTRL isn't a constant; I should probably try compiling my patches before sending them in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 From noreply@sourceforge.net Wed Mar 21 16:29:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 08:29:30 -0800 Subject: [Patches] [ python-Patches-410223 ] Replaces and Replaced-By PEP headers Message-ID: Patches item #410223, was updated on 2001-03-20 19:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410223&group_id=5470 Category: documentation Group: None >Status: Closed Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Barry Warsaw (bwarsaw) Summary: Replaces and Replaced-By PEP headers Initial Comment: The attached patch adds text to PEP 1 describing the Replaced-By and Replaces headers, and patches pep2html.py to hyperlink those headers properly. Barry, feel free to rewrite/modify and check in at your leisure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410223&group_id=5470 From noreply@sourceforge.net Wed Mar 21 16:35:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 08:35:01 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Wed Mar 21 16:50:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 08:50:44 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open >Priority: 7 Submitted By: Michael Hudson (mwh) >Assigned to: Guido van Rossum (gvanrossum) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Wed Mar 21 19:10:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 11:10:07 -0800 Subject: [Patches] [ python-Patches-410336 ] pydoc patch for strings & lists Message-ID: Patches item #410336, was updated on 2001-03-21 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410336&group_id=5470 Category: library Group: None Status: Open Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Ka-Ping Yee (ping) Summary: pydoc patch for strings & lists Initial Comment: This itty bitty patch allows pydoc to display string and list methods. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410336&group_id=5470 From noreply@sourceforge.net Wed Mar 21 19:19:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 11:19:28 -0800 Subject: [Patches] [ python-Patches-410336 ] pydoc patch for strings & lists Message-ID: Patches item #410336, was updated on 2001-03-21 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410336&group_id=5470 Category: library Group: None >Status: Closed Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Ka-Ping Yee (ping) Summary: pydoc patch for strings & lists Initial Comment: This itty bitty patch allows pydoc to display string and list methods. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-03-21 11:19 Message: Logged In: YES user_id=44345 bag this - i didn't realize there were both HTML and text formatters... I'll eventually work up something more complete. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410336&group_id=5470 From noreply@sourceforge.net Wed Mar 21 19:29:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 11:29:11 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-21 11:29 Message: Logged In: YES user_id=31435 After talking with Guido, I checked in a variant of next- dict.diff; but didn't touch the rest of this. dictobject.c rev 2.74. PyDict_Next is now safe to use in loops that merely modify the values associated with existing dict keys via Py_SetItem (). Other kinds of mutation are still blow-up-at-your-own- risk. Note to Jeremy: it is NOT enough merely that the number of keys remain the same. No existing key can be deleted, nor any new key inserted, during the loop. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Wed Mar 21 22:29:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 14:29:28 -0800 Subject: [Patches] [ python-Patches-410395 ] death module Message-ID: Patches item #410395, was updated on 2001-03-21 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410395&group_id=5470 Category: Modules Group: None Status: Open Priority: 3 Submitted By: Jeremy Hylton (jhylton) Assigned to: Barry Warsaw (bwarsaw) Summary: death module Initial Comment: This module makes it easy to generate core dumps from Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410395&group_id=5470 From noreply@sourceforge.net Wed Mar 21 22:40:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 14:40:21 -0800 Subject: [Patches] [ python-Patches-410395 ] death module Message-ID: Patches item #410395, was updated on 2001-03-21 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410395&group_id=5470 Category: Modules Group: None Status: Open Priority: 3 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jeremy Hylton (jhylton) Summary: death module Initial Comment: This module makes it easy to generate core dumps from Python. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-21 14:40 Message: Logged In: YES user_id=12800 Looks good, a few comments. - the deathmodule.c patch was included three times! Guess you really want it to die. - you should include a death_die_abort() which calls the abort() function. - the functions return NULL but don't set an exception. while I agree it's highly unlikely that the functions actually return, you might want to do something saner than cause a SystemError if they magically manage to return on some platform. - be sure that this module isn't built/enabled by default! if an app had a hole which allowed this module to be invoked, it would be a nice DoS attack. - you may want to coordinate a bit with Dave Beazley based on his IPC9 presentation. Assigning back to Jeremy with a +1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410395&group_id=5470 From noreply@sourceforge.net Wed Mar 21 23:49:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 15:49:51 -0800 Subject: [Patches] [ python-Patches-405792 ] Run configure instead of config.status Message-ID: Patches item #405792, was updated on 2001-03-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: Run configure instead of config.status Initial Comment: The config.status script does not check configure's exit status. This causes an infinite loop if configure is newer than config.status and configure fails for some reason. One way to test this is to first run configure and then add an "exit 1" line at the top of configure. Running make will cause an infinite loop. I think its best to avoid using config.status all together. Its easy to save the configure arguments. Assigned to Guido since it looks like he originally add the WITH variable. Will anyone care if we get rid of it? ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 15:49 Message: Logged In: YES user_id=35752 Will most likely fix bug "[ #231222 ] Python-2.1a2: HP make continiously runs the configure script". ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:53 Message: Logged In: YES user_id=35752 Yah! Guido, please take a look. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:50 Message: Logged In: YES user_id=35752 Please Mr SF, let me upload a patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:16 Message: Logged In: YES user_id=6380 Neil, can you propose a patch? I'm not quite clear what you are proposing here -- a patch would be most clarifying! Assign back to me with patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 From noreply@sourceforge.net Wed Mar 21 23:51:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 15:51:12 -0800 Subject: [Patches] [ python-Patches-410407 ] finishing touches on __future__ support Message-ID: Patches item #410407, was updated on 2001-03-21 15:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 8 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: finishing touches on __future__ support Initial Comment: This patch threads nested_scopes flags throughout the interpreter (mostly pythonrun.c) to support execfile, exec, and compile as described in PEP 236. It also supports -i in the natural way. If you run python -i foo.py and foo.py contains a future statement, that future statement is still in effect when you reach the interactive interpreter prompt. There are a mess of new functions that now take a PyCompilerFlags * argument. It's a total mess, but we hopefully we can remove it all as soon as we release 2.2. It's only necessary for 2.1 to support future nested scopes. Note that the Windows main.c may also need to be modified. I've got no idea if it has something like -i. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 From noreply@sourceforge.net Wed Mar 21 23:59:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 15:59:06 -0800 Subject: [Patches] [ python-Patches-405792 ] Run configure instead of config.status Message-ID: Patches item #405792, was updated on 2001-03-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Run configure instead of config.status Initial Comment: The config.status script does not check configure's exit status. This causes an infinite loop if configure is newer than config.status and configure fails for some reason. One way to test this is to first run configure and then add an "exit 1" line at the top of configure. Running make will cause an infinite loop. I think its best to avoid using config.status all together. Its easy to save the configure arguments. Assigned to Guido since it looks like he originally add the WITH variable. Will anyone care if we get rid of it? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 15:59 Message: Logged In: YES user_id=6380 Yes, this looks good. Go ahead and check it in! ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 15:49 Message: Logged In: YES user_id=35752 Will most likely fix bug "[ #231222 ] Python-2.1a2: HP make continiously runs the configure script". ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:53 Message: Logged In: YES user_id=35752 Yah! Guido, please take a look. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:50 Message: Logged In: YES user_id=35752 Please Mr SF, let me upload a patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:16 Message: Logged In: YES user_id=6380 Neil, can you propose a patch? I'm not quite clear what you are proposing here -- a patch would be most clarifying! Assign back to me with patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 From noreply@sourceforge.net Wed Mar 21 23:59:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 15:59:55 -0800 Subject: [Patches] [ python-Patches-400938 ] [Draft] libpython as shared library (.so) on Linux Message-ID: Patches item #400938, was updated on 2000-07-19 13:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Gregor Hoffleit (flight) Assigned to: Neil Schemenauer (nascheme) Summary: [Draft] libpython as shared library (.so) on Linux Initial Comment: ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 15:59 Message: Logged In: YES user_id=35752 We're going to have to create a new patch to do this. This one is way too out of date. Maybe for 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 14:46 Message: I'm reassigning this to Neil. Neil, can you see if you can integrate this into your flat Makefile? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-17 15:09 Message: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-01-17 14:46 Message: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-11-01 03:32 Message: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-26 14:13 Message: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-08-23 09:26 Message: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-16 00:40 Message: I suggest we postpone it. It isn't really complete (only works on real distributions ), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 10:52 Message: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit (flight) Date: 2000-07-19 14:10 Message: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 From noreply@sourceforge.net Thu Mar 22 00:04:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 16:04:42 -0800 Subject: [Patches] [ python-Patches-410407 ] finishing touches on __future__ support Message-ID: Patches item #410407, was updated on 2001-03-21 15:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 8 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jeremy Hylton (jhylton) Summary: finishing touches on __future__ support Initial Comment: This patch threads nested_scopes flags throughout the interpreter (mostly pythonrun.c) to support execfile, exec, and compile as described in PEP 236. It also supports -i in the natural way. If you run python -i foo.py and foo.py contains a future statement, that future statement is still in effect when you reach the interactive interpreter prompt. There are a mess of new functions that now take a PyCompilerFlags * argument. It's a total mess, but we hopefully we can remove it all as soon as we release 2.2. It's only necessary for 2.1 to support future nested scopes. Note that the Windows main.c may also need to be modified. I've got no idea if it has something like -i. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:04 Message: Logged In: YES user_id=6380 After a cursory skim this looks right. Note that the Windows main just calls Py_Main(argc, argv), so it should automatically be getting the changes. Go check it in! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 From noreply@sourceforge.net Thu Mar 22 00:06:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 16:06:25 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=6380 This is closed now as far as I'm concerned. The policy decision is that during a PyDict_Next() walk, you may only call PyDict_SetItem() to replace the value for an existing key. Thanks Michael and Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-21 11:29 Message: Logged In: YES user_id=31435 After talking with Guido, I checked in a variant of next- dict.diff; but didn't touch the rest of this. dictobject.c rev 2.74. PyDict_Next is now safe to use in loops that merely modify the values associated with existing dict keys via Py_SetItem (). Other kinds of mutation are still blow-up-at-your-own- risk. Note to Jeremy: it is NOT enough merely that the number of keys remain the same. No existing key can be deleted, nor any new key inserted, during the loop. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Thu Mar 22 00:06:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 16:06:54 -0800 Subject: [Patches] [ python-Patches-410407 ] finishing touches on __future__ support Message-ID: Patches item #410407, was updated on 2001-03-21 15:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 8 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: finishing touches on __future__ support Initial Comment: This patch threads nested_scopes flags throughout the interpreter (mostly pythonrun.c) to support execfile, exec, and compile as described in PEP 236. It also supports -i in the natural way. If you run python -i foo.py and foo.py contains a future statement, that future statement is still in effect when you reach the interactive interpreter prompt. There are a mess of new functions that now take a PyCompilerFlags * argument. It's a total mess, but we hopefully we can remove it all as soon as we release 2.2. It's only necessary for 2.1 to support future nested scopes. Note that the Windows main.c may also need to be modified. I've got no idea if it has something like -i. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=31435 Windows should be fine, Jeremy -- but thanks for worrying about it . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:04 Message: Logged In: YES user_id=6380 After a cursory skim this looks right. Note that the Windows main just calls Py_Main(argc, argv), so it should automatically be getting the changes. Go check it in! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 From noreply@sourceforge.net Thu Mar 22 00:07:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 16:07:45 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) >Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:07 Message: Logged In: YES user_id=6380 Postponing this until after 2.1 -- there are too many little nagging design decisions about the API. Ping is disappointed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:57 Message: Logged In: YES user_id=6380 Ping, I was testing this in a loop looking for leaks (none found BTW) and I noticed that it couldn't be killed by control-C. Can you see a reason why? Also, I was looking at the Python code in traceback.py and it has a limit on how many frames it prints (which defaults to sys.tracebacklimit). Would it make sense to be able to pass that into sys.excepthook() as well? Note; I'm seeing enough little questions that make me think this is best left until after 2.1 is released... Would you be very disappointed? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-18 15:33 Message: Logged In: NO PS-- I would suggest to store a copy in sys.__excepthook__, just like sys.__stdout__. Guido (too lazy to log in on SF) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:10 Message: Logged In: YES user_id=6380 Very close. Thanks, Ping! Mandatory improvement:most of the times where you use fprintf(stderr, ...) you should be using PySys_WriteStderr(...). The only time when it's OK to use stderr directly is is when sys.stderr is not found. An idea which I'm not sure of: maybe the PyErr_Display() function could take a PyObject * 4th argument being the file object to which the traceback should be written. This makes the logic of its callers a bit more convoluted, unless you let it default to NULL (which might be the best thing anyway). Also... I guess we need a few lines of documentation for sys.excepthook, for PyErr_Display(), and for the changed semantics of PyErr_Print[Ex](). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Thu Mar 22 00:33:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 16:33:08 -0800 Subject: [Patches] [ python-Patches-405792 ] Run configure instead of config.status Message-ID: Patches item #405792, was updated on 2001-03-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Run configure instead of config.status Initial Comment: The config.status script does not check configure's exit status. This causes an infinite loop if configure is newer than config.status and configure fails for some reason. One way to test this is to first run configure and then add an "exit 1" line at the top of configure. Running make will cause an infinite loop. I think its best to avoid using config.status all together. Its easy to save the configure arguments. Assigned to Guido since it looks like he originally add the WITH variable. Will anyone care if we get rid of it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 15:59 Message: Logged In: YES user_id=6380 Yes, this looks good. Go ahead and check it in! ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 15:49 Message: Logged In: YES user_id=35752 Will most likely fix bug "[ #231222 ] Python-2.1a2: HP make continiously runs the configure script". ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:53 Message: Logged In: YES user_id=35752 Yah! Guido, please take a look. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-20 20:50 Message: Logged In: YES user_id=35752 Please Mr SF, let me upload a patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 14:16 Message: Logged In: YES user_id=6380 Neil, can you propose a patch? I'm not quite clear what you are proposing here -- a patch would be most clarifying! Assign back to me with patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405792&group_id=5470 From noreply@sourceforge.net Thu Mar 22 00:38:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 16:38:52 -0800 Subject: [Patches] [ python-Patches-407149 ] 'D' format option for Py_BuildValue Message-ID: Patches item #407149, was updated on 2001-03-08 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407149&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: 'D' format option for Py_BuildValue Initial Comment: This patch add the 'D' format specifier to Py_BuildValue for constructing complex Python numbers out of a Py_complex C structure. A patch to the documentation is included. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 16:38 Message: Logged In: YES user_id=35752 This patch has been applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407149&group_id=5470 From noreply@sourceforge.net Thu Mar 22 02:49:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 18:49:07 -0800 Subject: [Patches] [ python-Patches-408627 ] frame.lookup_name Message-ID: Patches item #408627, was updated on 2001-03-14 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: frame.lookup_name Initial Comment: This method implements the functionality you want for string interpolation: given a frame, return the value that name is bound to in the frame's environment. Works for free variables. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-19 12:33 Message: Logged In: YES user_id=31392 We decided to scrap this approach, because it does a linear search over the names in the code object to figure out the right scope. If you look up all the names, this has quadratic cost. Instead, we'll create a dictionary with all the name bindings. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-14 21:53 Message: Logged In: YES user_id=45338 I hate SourceForge. It just took three or four tries, reloading various pages on the looong path between the login screen and the patch detail screen, to convince it that i was logged in. Anyway, here's what i wanted to say: lookup() would be a fine name for a method, but then again, why not just use mp_subscript? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-14 19:48 Message: Logged In: YES user_id=12800 Certainly seems to do what I want, thanks. Three questions, probably for the BDFL: - is lookup_name() the best name for the method? The underscore is a little ugly to me. - should lookup_name() take an optional failobj, a la dict.get() which, if provided and the name is missing returns failobj instead of raising NameError? NameError is fine if failobj is omitted. - does it make sense to be able to find out where a name was found, i.e. in which scope? I can't think of a particular use for this, but the API might be for frame.which_scope(name) to return an integer which signifies how many lexical scopes up the name was found. e.g. 0 == locals, 1 == immediately nested scope and so on. Maybe special value -1 means global. Ah, on second thought, that seems more confusing than necessary. Assigning back to Jeremy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408627&group_id=5470 From noreply@sourceforge.net Thu Mar 22 02:48:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 18:48:56 -0800 Subject: [Patches] [ python-Patches-410407 ] finishing touches on __future__ support Message-ID: Patches item #410407, was updated on 2001-03-21 15:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 8 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: finishing touches on __future__ support Initial Comment: This patch threads nested_scopes flags throughout the interpreter (mostly pythonrun.c) to support execfile, exec, and compile as described in PEP 236. It also supports -i in the natural way. If you run python -i foo.py and foo.py contains a future statement, that future statement is still in effect when you reach the interactive interpreter prompt. There are a mess of new functions that now take a PyCompilerFlags * argument. It's a total mess, but we hopefully we can remove it all as soon as we release 2.2. It's only necessary for 2.1 to support future nested scopes. Note that the Windows main.c may also need to be modified. I've got no idea if it has something like -i. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 18:48 Message: Logged In: YES user_id=31392 checked in (too many file to bother listing the rev numbers) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=31435 Windows should be fine, Jeremy -- but thanks for worrying about it . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:04 Message: Logged In: YES user_id=6380 After a cursory skim this looks right. Note that the Windows main just calls Py_Main(argc, argv), so it should automatically be getting the changes. Go check it in! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410407&group_id=5470 From noreply@sourceforge.net Thu Mar 22 05:02:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 21:02:42 -0800 Subject: [Patches] [ python-Patches-410465 ] Allow pre-encoded strings as filenames Message-ID: Patches item #410465, was updated on 2001-03-21 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Allow pre-encoded strings as filenames Initial Comment: This patch enables most filename parameters to use pre- encoded strings. On Windows, the default of "mbcs" is used. On all other platforms, the default filename encoding is the same as the general default encoding, which in reality means there is no functional change. However, other platforms can simply plugin their own encodings. Rationalle: os.listdir() etc already return pre- encoded strings on some platforms (notably Windows). These pre-encoded strings may be used now for all these functions - however, if you convert this encoded string to a Unicode string, it can not be used to open the file. This patch enables either a pre-encoded string to work (as now) or a Unicode representation of that same string (unlike now) Things of note: * I invented a new "Es" PyArg_ParseTuple marker. This is very similar to "es", except it leaves string objects alone assuming they are already encoded correctly. "es" assumes a string in the default encoding which it will then encode in the new characterset - ie, a pre-encoded string fails here. * This means that all affected functions have an extra string copy. This copy still happens even when strings are passed, and even on platforms where no Unicode filesystem support exists. The only other alternative was to make a much uglier patch, somehow using string objects in-place, but converting and freeing the buffer when Unicode. This could be done if desired, but I'm not sure the added code complexity is worth it. * New method on win32: nt._getpathname(). This is almost identical to win32api.GetPathName(), except it handles encoded strings. ntpath.py has also been changed to work with this. A hidden bonus of this patch is that it will make os.abspath() work identically regardless of the Win32 extensions being installed. * Tested on Linux, Windows 98 and Windows 2k. Still working out how to build Python on my BeOs box :) * New test for these semantics added. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 From noreply@sourceforge.net Thu Mar 22 05:04:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Mar 2001 21:04:53 -0800 Subject: [Patches] [ python-Patches-410465 ] Allow pre-encoded strings as filenames Message-ID: Patches item #410465, was updated on 2001-03-21 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Allow pre-encoded strings as filenames Initial Comment: This patch enables most filename parameters to use pre- encoded strings. On Windows, the default of "mbcs" is used. On all other platforms, the default filename encoding is the same as the general default encoding, which in reality means there is no functional change. However, other platforms can simply plugin their own encodings. Rationalle: os.listdir() etc already return pre- encoded strings on some platforms (notably Windows). These pre-encoded strings may be used now for all these functions - however, if you convert this encoded string to a Unicode string, it can not be used to open the file. This patch enables either a pre-encoded string to work (as now) or a Unicode representation of that same string (unlike now) Things of note: * I invented a new "Es" PyArg_ParseTuple marker. This is very similar to "es", except it leaves string objects alone assuming they are already encoded correctly. "es" assumes a string in the default encoding which it will then encode in the new characterset - ie, a pre-encoded string fails here. * This means that all affected functions have an extra string copy. This copy still happens even when strings are passed, and even on platforms where no Unicode filesystem support exists. The only other alternative was to make a much uglier patch, somehow using string objects in-place, but converting and freeing the buffer when Unicode. This could be done if desired, but I'm not sure the added code complexity is worth it. * New method on win32: nt._getpathname(). This is almost identical to win32api.GetPathName(), except it handles encoded strings. ntpath.py has also been changed to work with this. A hidden bonus of this patch is that it will make os.abspath() work identically regardless of the Win32 extensions being installed. * Tested on Linux, Windows 98 and Windows 2k. Still working out how to build Python on my BeOs box :) * New test for these semantics added. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2001-03-21 21:04 Message: Logged In: YES user_id=14198 doh - forgot to click the checkbox ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 From noreply@sourceforge.net Thu Mar 22 08:28:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 00:28:31 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Closed Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-03-22 00:28 Message: Logged In: YES user_id=6656 What about the doc changes and the test cases? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=6380 This is closed now as far as I'm concerned. The policy decision is that during a PyDict_Next() walk, you may only call PyDict_SetItem() to replace the value for an existing key. Thanks Michael and Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-21 11:29 Message: Logged In: YES user_id=31435 After talking with Guido, I checked in a variant of next- dict.diff; but didn't touch the rest of this. dictobject.c rev 2.74. PyDict_Next is now safe to use in loops that merely modify the values associated with existing dict keys via Py_SetItem (). Other kinds of mutation are still blow-up-at-your-own- risk. Note to Jeremy: it is NOT enough merely that the number of keys remain the same. No existing key can be deleted, nor any new key inserted, during the loop. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Thu Mar 22 15:49:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 07:49:01 -0800 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None >Status: Open Priority: 7 Submitted By: Michael Hudson (mwh) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 07:49 Message: Logged In: YES user_id=6380 Assigned to Fred for docs. I believe the doc changes are in the uploaded files. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-22 00:28 Message: Logged In: YES user_id=6656 What about the doc changes and the test cases? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=6380 This is closed now as far as I'm concerned. The policy decision is that during a PyDict_Next() walk, you may only call PyDict_SetItem() to replace the value for an existing key. Thanks Michael and Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-21 11:29 Message: Logged In: YES user_id=31435 After talking with Guido, I checked in a variant of next- dict.diff; but didn't touch the rest of this. dictobject.c rev 2.74. PyDict_Next is now safe to use in loops that merely modify the values associated with existing dict keys via Py_SetItem (). Other kinds of mutation are still blow-up-at-your-own- risk. Note to Jeremy: it is NOT enough merely that the number of keys remain the same. No existing key can be deleted, nor any new key inserted, during the loop. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Thu Mar 22 16:24:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 08:24:56 -0800 Subject: [Patches] [ python-Patches-407434 ] Meta-data XML output Message-ID: Patches item #407434, was updated on 2001-03-09 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 Category: distutils Group: None >Status: Closed Priority: 5 Submitted By: Amos Latteier (amosl) Assigned to: A.M. Kuchling (akuchling) Summary: Meta-data XML output Initial Comment: This patch improves the DistributionMetadata class. It adds the ability to save and load meta-data to and from simple XML files. This is needed since my experience shows that it is often impossible to extract meta-data from setup.py files. This patch will enable programs like the catalog to read distribution metadata without running setup.py. It also beefs up the DistributionMetadata class so that it now functions like a dictionary, rather than an empty class. This means that getting data is more intuitive and meta-data names no longer need to be legal Python identifiers. Finally the patch fixes the sdist and bdist_wininst modules to work correctly with the new DistributionMetadata class. Note: IMHO, using DistributionMetadata instances in now more pleasant. The next step is to make meta-data be written to a file (metadata.xml) when a distribution is created. I wasn't sure where the right place to do this was, so I haven't included a patch for it. All that is needed though is something like the following: m=distribution.metadata f=open('metadata.xml', 'wb') m.write_data(f) f.close() The distutils themselves won't have any need to read meta-data files, but other programs such as the catalog will. Those programs can do the following: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping meta-data names to values ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-03-22 08:24 Message: Logged In: YES user_id=11375 Checked in. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-20 18:52 Message: Logged In: YES user_id=11375 Final version, and believed ready to check in. write_pkg_info() is now a method on the DistributionMetadata class as suggested by Amos, and a finalize_options() method has been added to Distribution. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-20 07:03 Message: Logged In: YES user_id=11375 Here's a different patch, not really derived from Amos's, that writes a PKG-INFO file when generating a source distribution. Still to resolve: * Is there a finalize_options() on the Distribution class where the keywords and platforms values can be converted from strings to lists? * Documentation. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-10 14:25 Message: Logged In: YES user_id=11375 That worked. The patch looks reasonable. There's little point in checking it in at this point, though, until we settle on the metadata fields and decide the XML-vs-other-formats question. ---------------------------------------------------------------------- Comment By: Amos Latteier (amosl) Date: 2001-03-10 13:58 Message: Logged In: YES user_id=157880 I am attempting to upload the patch again. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-10 11:51 Message: Logged In: YES user_id=11375 You seem to have run into the SourceForge file upload bug, because there isn't a patch attached. You may want to try again, or put it on the Web somewhere. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407434&group_id=5470 From noreply@sourceforge.net Thu Mar 22 16:58:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 08:58:15 -0800 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was updated on 2001-03-22 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Category: Windows Group: None Status: Open Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:36:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:36:18 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches item #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 1 Submitted By: Thomas Wouters (twouters) >Assigned to: Nobody/Anonymous (nobody) Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1 is released. Status set to postponed and priority lowered. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:40:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:40:17 -0800 Subject: [Patches] [ python-Patches-405952 ] cmd.py uses raw_input(); eats SIGCLD Message-ID: Patches item #405952, was updated on 2001-03-04 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 Category: library Group: None Status: Open >Priority: 6 Submitted By: Anthony Baxter (anthony_baxter) >Assigned to: Guido van Rossum (gvanrossum) Summary: cmd.py uses raw_input(); eats SIGCLD Initial Comment: I discovered a rather nasty side effect of the standard cmd.py library today. If it's sitting inside raw_input(), any SIGCLDs that get sent to your application get silently eaten and ignored. I'm assuming that this is something that readline is thoughtfully doing for me. This patch adds an instance attr that allows the user to select to not use raw_input(), but instead use sys.stdin.readline() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:48:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:48:15 -0800 Subject: [Patches] [ python-Patches-410267 ] some additional constants for termios Message-ID: Patches item #410267, was updated on 2001-03-21 01:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some additional constants for termios Initial Comment: This adds a pile of constants that were in my old plat-linux2/TERMIOS.py that aren't in the new termios.c. I'm not sure all of them have valid uses, but some of them certainly do (I noticed that TIOCGWINSZ was missing). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:17 Message: Logged In: YES user_id=6656 CTRL isn't a constant; I should probably try compiling my patches before sending them in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:48:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:48:27 -0800 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was updated on 2001-03-22 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Category: Windows Group: None Status: Open Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Tim Peters (tim_one) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:48:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:48:56 -0800 Subject: [Patches] [ python-Patches-409287 ] ssl fix when using _socketobject Message-ID: Patches item #409287, was updated on 2001-03-16 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Guido van Rossum (gvanrossum) Summary: ssl fix when using _socketobject Initial Comment: On windows and other platforms _socketobject instances are used instead of the raw extension type. This breaks the _socket.ssl function which is expecting an extension type parameter. This patch makes a wrapper for socket.ssl similar to socket.socket when _socketobjects are used. This patch is for 2.0 but it looks like it will work the same in 2.1 *** socket.orig.py Fri Mar 16 16:23:38 2001 --- socket.py Fri Mar 16 16:25:52 2001 *************** *** 51,58 **** --- 51,67 ---- except NameError: _realsocketcall = socket + try: + _realsslcall + except NameError: + _realsslcall = ssl + def socket(family, type, proto=0): return _socketobject(_realsocketcall(family, type, proto)) + + def ssl(sock, keyfile=None, certfile=None): + return _realsslcall(sock._sock, keyfile, certfile) + # WSA error codes ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:49:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:49:06 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: documentation Group: None Status: Open >Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:53:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:53:53 -0800 Subject: [Patches] [ python-Patches-405122 ] webbrowser fix Message-ID: Patches item #405122, was updated on 2001-03-01 06:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) >Assigned to: Ka-Ping Yee (ping) Summary: webbrowser fix Initial Comment: Put the word "Web" in the synopsis line. Remove the -no-about-splash option, as it prevents this module from working with Netscape 3. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 10:42 Message: Logged In: YES user_id=6380 Fixing ESR's finger error -- don't reject this yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 From noreply@sourceforge.net Thu Mar 22 20:55:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 12:55:16 -0800 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was updated on 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Ka-Ping Yee (ping) >Assigned to: Ka-Ping Yee (ping) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:07 Message: Logged In: YES user_id=6380 Postponing this until after 2.1 -- there are too many little nagging design decisions about the API. Ping is disappointed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:57 Message: Logged In: YES user_id=6380 Ping, I was testing this in a loop looking for leaks (none found BTW) and I noticed that it couldn't be killed by control-C. Can you see a reason why? Also, I was looking at the Python code in traceback.py and it has a limit on how many frames it prints (which defaults to sys.tracebacklimit). Would it make sense to be able to pass that into sys.excepthook() as well? Note; I'm seeing enough little questions that make me think this is best left until after 2.1 is released... Would you be very disappointed? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-18 15:33 Message: Logged In: NO PS-- I would suggest to store a copy in sys.__excepthook__, just like sys.__stdout__. Guido (too lazy to log in on SF) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:10 Message: Logged In: YES user_id=6380 Very close. Thanks, Ping! Mandatory improvement:most of the times where you use fprintf(stderr, ...) you should be using PySys_WriteStderr(...). The only time when it's OK to use stderr directly is is when sys.stderr is not found. An idea which I'm not sure of: maybe the PyErr_Display() function could take a PyObject * 4th argument being the file object to which the traceback should be written. This makes the logic of its callers a bit more convoluted, unless you let it default to NULL (which might be the best thing anyway). Also... I guess we need a few lines of documentation for sys.excepthook, for PyErr_Display(), and for the changed semantics of PyErr_Print[Ex](). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Thu Mar 22 21:35:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 13:35:00 -0800 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was updated on 2001-03-22 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Category: Windows Group: None Status: Open Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Tim Peters (tim_one) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-22 13:35 Message: Logged In: YES user_id=31435 /F, can you add a doc patch (for os.statvfs) that says enough so that a Windows user has some chance of guessing what this function returns? BTW, I have no problem w/ returning zeroes instead of Nones. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply@sourceforge.net Thu Mar 22 21:36:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 13:36:21 -0800 Subject: [Patches] [ python-Patches-409287 ] ssl fix when using _socketobject Message-ID: Patches item #409287, was updated on 2001-03-16 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Mark Hammond (mhammond) Summary: ssl fix when using _socketobject Initial Comment: On windows and other platforms _socketobject instances are used instead of the raw extension type. This breaks the _socket.ssl function which is expecting an extension type parameter. This patch makes a wrapper for socket.ssl similar to socket.socket when _socketobjects are used. This patch is for 2.0 but it looks like it will work the same in 2.1 *** socket.orig.py Fri Mar 16 16:23:38 2001 --- socket.py Fri Mar 16 16:25:52 2001 *************** *** 51,58 **** --- 51,67 ---- except NameError: _realsocketcall = socket + try: + _realsslcall + except NameError: + _realsslcall = ssl + def socket(family, type, proto=0): return _socketobject(_realsocketcall(family, type, proto)) + + def ssl(sock, keyfile=None, certfile=None): + return _realsslcall(sock._sock, keyfile, certfile) + # WSA error codes ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 From noreply@sourceforge.net Thu Mar 22 21:37:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 13:37:00 -0800 Subject: [Patches] [ python-Patches-409287 ] ssl fix when using _socketobject Message-ID: Patches item #409287, was updated on 2001-03-16 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Guido van Rossum (gvanrossum) Summary: ssl fix when using _socketobject Initial Comment: On windows and other platforms _socketobject instances are used instead of the raw extension type. This breaks the _socket.ssl function which is expecting an extension type parameter. This patch makes a wrapper for socket.ssl similar to socket.socket when _socketobjects are used. This patch is for 2.0 but it looks like it will work the same in 2.1 *** socket.orig.py Fri Mar 16 16:23:38 2001 --- socket.py Fri Mar 16 16:25:52 2001 *************** *** 51,58 **** --- 51,67 ---- except NameError: _realsocketcall = socket + try: + _realsslcall + except NameError: + _realsslcall = ssl + def socket(family, type, proto=0): return _socketobject(_realsocketcall(family, type, proto)) + + def ssl(sock, keyfile=None, certfile=None): + return _realsslcall(sock._sock, keyfile, certfile) + # WSA error codes ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 From noreply@sourceforge.net Thu Mar 22 21:45:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 13:45:45 -0800 Subject: [Patches] [ python-Patches-410465 ] Allow pre-encoded strings as filenames Message-ID: Patches item #410465, was updated on 2001-03-21 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Allow pre-encoded strings as filenames Initial Comment: This patch enables most filename parameters to use pre- encoded strings. On Windows, the default of "mbcs" is used. On all other platforms, the default filename encoding is the same as the general default encoding, which in reality means there is no functional change. However, other platforms can simply plugin their own encodings. Rationalle: os.listdir() etc already return pre- encoded strings on some platforms (notably Windows). These pre-encoded strings may be used now for all these functions - however, if you convert this encoded string to a Unicode string, it can not be used to open the file. This patch enables either a pre-encoded string to work (as now) or a Unicode representation of that same string (unlike now) Things of note: * I invented a new "Es" PyArg_ParseTuple marker. This is very similar to "es", except it leaves string objects alone assuming they are already encoded correctly. "es" assumes a string in the default encoding which it will then encode in the new characterset - ie, a pre-encoded string fails here. * This means that all affected functions have an extra string copy. This copy still happens even when strings are passed, and even on platforms where no Unicode filesystem support exists. The only other alternative was to make a much uglier patch, somehow using string objects in-place, but converting and freeing the buffer when Unicode. This could be done if desired, but I'm not sure the added code complexity is worth it. * New method on win32: nt._getpathname(). This is almost identical to win32api.GetPathName(), except it handles encoded strings. ntpath.py has also been changed to work with this. A hidden bonus of this patch is that it will make os.abspath() work identically regardless of the Win32 extensions being installed. * Tested on Linux, Windows 98 and Windows 2k. Still working out how to build Python on my BeOs box :) * New test for these semantics added. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:45 Message: Logged In: YES user_id=6380 Mark, I don't think you expected to get this into 2.1, did you? It's way too big. Also, I think your patch to posixmodule.c has some bugs -- if I understand correctly, the format string "Es" requires two arguments, the encoding and the address of the C string pointer; but several functions (posix_rename and onwards) don't pass the encoding name. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-03-21 21:04 Message: Logged In: YES user_id=14198 doh - forgot to click the checkbox ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 From noreply@sourceforge.net Thu Mar 22 21:59:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 13:59:47 -0800 Subject: [Patches] [ python-Patches-405952 ] cmd.py uses raw_input(); eats SIGCLD Message-ID: Patches item #405952, was updated on 2001-03-04 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 Category: library Group: None >Status: Closed Priority: 6 Submitted By: Anthony Baxter (anthony_baxter) Assigned to: Guido van Rossum (gvanrossum) Summary: cmd.py uses raw_input(); eats SIGCLD Initial Comment: I discovered a rather nasty side effect of the standard cmd.py library today. If it's sitting inside raw_input(), any SIGCLDs that get sent to your application get silently eaten and ignored. I'm assuming that this is something that readline is thoughtfully doing for me. This patch adds an instance attr that allows the user to select to not use raw_input(), but instead use sys.stdin.readline() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:59 Message: Logged In: YES user_id=6380 OK, applied, ready for 2.1b2. I changed the try/except to only cover the raw_input() call. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 From noreply@sourceforge.net Thu Mar 22 22:10:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 14:10:27 -0800 Subject: [Patches] [ python-Patches-410465 ] Allow pre-encoded strings as filenames Message-ID: Patches item #410465, was updated on 2001-03-21 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Allow pre-encoded strings as filenames Initial Comment: This patch enables most filename parameters to use pre- encoded strings. On Windows, the default of "mbcs" is used. On all other platforms, the default filename encoding is the same as the general default encoding, which in reality means there is no functional change. However, other platforms can simply plugin their own encodings. Rationalle: os.listdir() etc already return pre- encoded strings on some platforms (notably Windows). These pre-encoded strings may be used now for all these functions - however, if you convert this encoded string to a Unicode string, it can not be used to open the file. This patch enables either a pre-encoded string to work (as now) or a Unicode representation of that same string (unlike now) Things of note: * I invented a new "Es" PyArg_ParseTuple marker. This is very similar to "es", except it leaves string objects alone assuming they are already encoded correctly. "es" assumes a string in the default encoding which it will then encode in the new characterset - ie, a pre-encoded string fails here. * This means that all affected functions have an extra string copy. This copy still happens even when strings are passed, and even on platforms where no Unicode filesystem support exists. The only other alternative was to make a much uglier patch, somehow using string objects in-place, but converting and freeing the buffer when Unicode. This could be done if desired, but I'm not sure the added code complexity is worth it. * New method on win32: nt._getpathname(). This is almost identical to win32api.GetPathName(), except it handles encoded strings. ntpath.py has also been changed to work with this. A hidden bonus of this patch is that it will make os.abspath() work identically regardless of the Win32 extensions being installed. * Tested on Linux, Windows 98 and Windows 2k. Still working out how to build Python on my BeOs box :) * New test for these semantics added. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2001-03-22 14:10 Message: Logged In: YES user_id=14198 I appreciate it is too late for 2.1 for a change of this size. I don't think posixmodule is wrong - at least not how you think :) posix_rename calls: return posix_2str(args, "EsEs:rename", rename); however, it is posix_2str that passes the encoding, not posix_rename itself. Ditto for posix_1str and posix_do_stat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:45 Message: Logged In: YES user_id=6380 Mark, I don't think you expected to get this into 2.1, did you? It's way too big. Also, I think your patch to posixmodule.c has some bugs -- if I understand correctly, the format string "Es" requires two arguments, the encoding and the address of the C string pointer; but several functions (posix_rename and onwards) don't pass the encoding name. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-03-21 21:04 Message: Logged In: YES user_id=14198 doh - forgot to click the checkbox ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 From noreply@sourceforge.net Thu Mar 22 22:12:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 14:12:31 -0800 Subject: [Patches] [ python-Patches-409287 ] ssl fix when using _socketobject Message-ID: Patches item #409287, was updated on 2001-03-16 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 Category: library Group: None >Status: Closed Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: ssl fix when using _socketobject Initial Comment: On windows and other platforms _socketobject instances are used instead of the raw extension type. This breaks the _socket.ssl function which is expecting an extension type parameter. This patch makes a wrapper for socket.ssl similar to socket.socket when _socketobjects are used. This patch is for 2.0 but it looks like it will work the same in 2.1 *** socket.orig.py Fri Mar 16 16:23:38 2001 --- socket.py Fri Mar 16 16:25:52 2001 *************** *** 51,58 **** --- 51,67 ---- except NameError: _realsocketcall = socket + try: + _realsslcall + except NameError: + _realsslcall = ssl + def socket(family, type, proto=0): return _socketobject(_realsocketcall(family, type, proto)) + + def ssl(sock, keyfile=None, certfile=None): + return _realsslcall(sock._sock, keyfile, certfile) + # WSA error codes ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 14:12 Message: Logged In: YES user_id=6380 I've fixed this. The patch is slightly different, it turns out that your patch doesn't work when _socket.ssl doesn't exist. Please test what I checked in because I don't have SSL on my Windows box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 From noreply@sourceforge.net Thu Mar 22 23:22:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 15:22:46 -0800 Subject: [Patches] [ python-Patches-405952 ] cmd.py uses raw_input(); eats SIGCLD Message-ID: Patches item #405952, was updated on 2001-03-04 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 Category: library Group: None Status: Closed Priority: 6 Submitted By: Anthony Baxter (anthony_baxter) Assigned to: Guido van Rossum (gvanrossum) Summary: cmd.py uses raw_input(); eats SIGCLD Initial Comment: I discovered a rather nasty side effect of the standard cmd.py library today. If it's sitting inside raw_input(), any SIGCLDs that get sent to your application get silently eaten and ignored. I'm assuming that this is something that readline is thoughtfully doing for me. This patch adds an instance attr that allows the user to select to not use raw_input(), but instead use sys.stdin.readline() ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-22 15:22 Message: Logged In: YES user_id=6656 nag, nag. the docs will get updated before 2.1, right? (not by me!) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:59 Message: Logged In: YES user_id=6380 OK, applied, ready for 2.1b2. I changed the try/except to only cover the raw_input() call. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 From noreply@sourceforge.net Fri Mar 23 02:48:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 18:48:02 -0800 Subject: [Patches] [ python-Patches-408597 ] quopri, soft line breaks and CRLF Message-ID: Patches item #408597, was updated on 2001-03-14 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408597&group_id=5470 Category: library Group: None >Status: Closed Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: quopri, soft line breaks and CRLF Initial Comment: This patch fixes a small problem with quopri: Soft Line Breaks (i.e. lines ending with '='; see RFC 1521 2.1 Rule #5) do not work with CRLF line endings, because \r will not be stripped off from the read line. This patch fixes this problem by adding \r to the whitespace characters that are stripped off of the end of the line. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 18:48 Message: Logged In: YES user_id=6380 Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=408597&group_id=5470 From noreply@sourceforge.net Fri Mar 23 02:47:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 18:47:54 -0800 Subject: [Patches] [ python-Patches-409044 ] Update tcl/tk/tix versions Message-ID: Patches item #409044, was updated on 2001-03-15 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 Category: Tkinter Group: None >Status: Closed Priority: 4 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Update tcl/tk/tix versions Initial Comment: A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library. Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings. The attached context diff is against 2.1b1, but it should apply to any 2.x version. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 18:47 Message: Logged In: YES user_id=6380 Checked in. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:18 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid for all Tk extensions, even for 2.0.x, as the -L must proceed *any* -l. Also, tix4.1.8.0 was never an official release, and most Linux releases are now distributing tix8.1.8.x. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-19 10:43 Message: Logged In: YES user_id=21627 For 1), I'd say this is historic garbage (I added some of it myself), so don't be afraid to rip it out. tkappinit.c predates the times that Tcl could do dynamic loading. Also, there is no need to operate the same way for all packages; just fix Tix for now. For 2), there are more problems when freezing: In Python 2.1, setup.py will build _tkinter as a dynamic module, and you can't freeze them, anyway. So anybody who wants to freeze would need a build where _tkinter is listed in Modules/Setup. Furthermore, you typically need Tix SAM libraries, or else the binary won't be stand-alone. Then you need static versions of libtcl.a, not shared ones. Anybody who wants to freeze with Tix needs a fair amount of local configuration, so supporting freeze is more complicated. For 3), if Tix does not appear in the C files at all, it can be removed from the .dsp file as well. For setup.py: You still can use Setup if you want to. The problem I see with static linkage that _tkinter then depends on Tix, so to install Python, you'll need to install Tix first; if you build Python not to depend on Tix, you can't use it even when it gets installed. Since most people use binary distributions, they get more out of dynamic loading than they'd get from static linking. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:36 Message: Logged In: YES user_id=33229 I would love to load Tix using package require, because that would be a "good thing", but there are some details: 1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking. My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved. I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach: 1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach. These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored. Don't hesitate to send me email as well idiscovery@users.sourceforge.net Mike. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 02:58 Message: Logged In: YES user_id=21627 I believe Tix integration should not rely on static linkage anymore. Instead, you should do self.tk.eval("package require Tix") and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations. Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409044&group_id=5470 From noreply@sourceforge.net Fri Mar 23 05:47:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Mar 2001 21:47:00 -0800 Subject: [Patches] [ python-Patches-410709 ] Condition.wait() and KeyboardInterrupt Message-ID: Patches item #410709, was updated on 2001-03-22 21:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 Category: Modules Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait() and KeyboardInterrupt Initial Comment: >My problem is: Condition.wait() is not protected against >KeyboardInterrupt. Fix is below. > >Regards, >Oleg. > >----------------------------- >#python 2.0, threading.py: > >... >class _Condition(_Verbose): >... > def wait(self, timeout=None): >... > saved_state = self._release_save() ># line to be inserted > try: >... ># line to be inserted > finally: > self._acquire_restore(saved_state) > ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 From noreply@sourceforge.net Fri Mar 23 16:07:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 08:07:41 -0800 Subject: [Patches] [ python-Patches-403666 ] Allow jython to use test_new Message-ID: Patches item #403666, was updated on 2001-02-07 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403666&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to use test_new Initial Comment: - Avoid the __builtins__ when jython. - The codestr must have a "global c". Otherwise jython will make c a local. This is a definate difference between the two implementation, but I think it is ok. - Skip the new.code() test which Jython never will implement. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 08:07 Message: Logged In: YES user_id=12800 Here's a more portable alternative, which I plan to commit for CPython 2.1b2. I agree with the "global c" addition; it's certainly not clear to me or Jeremy what c's binding should be in a code object compiled at module scope but bound to a new function. Forcing it to global makes sense (and btw, you might want to add a note to the CPython vs. Jython differences page). Further, while Jython doesn't have __builtins__, a more portable way to test this is to import __builtin__ and bind that to "__builtins__" in the g dict (I'm not sure why CPython includes this in the test -- but w/ this change both Jython and CPython pass). Finally, instead of testing for sys.platform, test for hasattr(new, 'code') for a more portable alternative (i.e. other platforms like C# may -- although I don't know -- have a similar restriction). Attached is the new version of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403666&group_id=5470 From noreply@sourceforge.net Fri Mar 23 16:13:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 08:13:42 -0800 Subject: [Patches] [ python-Patches-403666 ] Allow jython to use test_new Message-ID: Patches item #403666, was updated on 2001-02-07 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403666&group_id=5470 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to use test_new Initial Comment: - Avoid the __builtins__ when jython. - The codestr must have a "global c". Otherwise jython will make c a local. This is a definate difference between the two implementation, but I think it is ok. - Skip the new.code() test which Jython never will implement. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 08:13 Message: Logged In: YES user_id=12800 Accepting patch and closing this report. Patch (mis)named 401666.txt is applied in version 1.13 of test_new.py ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 08:07 Message: Logged In: YES user_id=12800 Here's a more portable alternative, which I plan to commit for CPython 2.1b2. I agree with the "global c" addition; it's certainly not clear to me or Jeremy what c's binding should be in a code object compiled at module scope but bound to a new function. Forcing it to global makes sense (and btw, you might want to add a note to the CPython vs. Jython differences page). Further, while Jython doesn't have __builtins__, a more portable way to test this is to import __builtin__ and bind that to "__builtins__" in the g dict (I'm not sure why CPython includes this in the test -- but w/ this change both Jython and CPython pass). Finally, instead of testing for sys.platform, test for hasattr(new, 'code') for a more portable alternative (i.e. other platforms like C# may -- although I don't know -- have a similar restriction). Attached is the new version of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403666&group_id=5470 From noreply@sourceforge.net Fri Mar 23 16:36:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 08:36:14 -0800 Subject: [Patches] [ python-Patches-409287 ] ssl fix when using _socketobject Message-ID: Patches item #409287, was updated on 2001-03-16 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: ssl fix when using _socketobject Initial Comment: On windows and other platforms _socketobject instances are used instead of the raw extension type. This breaks the _socket.ssl function which is expecting an extension type parameter. This patch makes a wrapper for socket.ssl similar to socket.socket when _socketobjects are used. This patch is for 2.0 but it looks like it will work the same in 2.1 *** socket.orig.py Fri Mar 16 16:23:38 2001 --- socket.py Fri Mar 16 16:25:52 2001 *************** *** 51,58 **** --- 51,67 ---- except NameError: _realsocketcall = socket + try: + _realsslcall + except NameError: + _realsslcall = ssl + def socket(family, type, proto=0): return _socketobject(_realsocketcall(family, type, proto)) + + def ssl(sock, keyfile=None, certfile=None): + return _realsslcall(sock._sock, keyfile, certfile) + # WSA error codes ---------------------------------------------------------------------- >Comment By: Robin Dunn (robind) Date: 2001-03-23 08:36 Message: Logged In: YES user_id=53955 Your change works for me when back-ported to 2.0's socket.py. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 14:12 Message: Logged In: YES user_id=6380 I've fixed this. The patch is slightly different, it turns out that your patch doesn't work when _socket.ssl doesn't exist. Please test what I checked in because I don't have SSL on my Windows box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409287&group_id=5470 From noreply@sourceforge.net Fri Mar 23 17:25:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 09:25:06 -0800 Subject: [Patches] [ python-Patches-405851 ] Allow jython to complete test_strftime Message-ID: Patches item #405851, was updated on 2001-03-04 09:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 >Category: library Group: None Status: Open >Priority: 3 Submitted By: Finn Bock (bckfnn) >Assigned to: M.-A. Lemburg (lemburg) Summary: Allow jython to complete test_strftime Initial Comment: Java always eun with a national locale. As a result the default strings from the "time" module is national. This path will assign a US locale and allow a successful test even when running with a non-us computer. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 09:25 Message: Logged In: YES user_id=12800 A couple of notes, then assignment back to Finn for determination. First, it seems to me that Jython ought to supply an _locale module for compatibility with CPython. That way, test_strftime.py could simply "import locale" and then do a locale.setlocale() without testing the platform. Second, it seems that Java has no "C" locale, but for CPython, the strftime tests require specifically "C" locale and not "en_US" locale (the latter of which breaks the tests). So, what is the right thing to do here? I'm attaching an alternative patch which ought to work today. Finn, please comment and I'll apply it for Python 2.1 final if it looks okay. Since Finn's not a CPython developer, I'm assigning the patch to MAL for a sanity check on the locale issues. MAL, feel free to assign back to me if my changes make sense. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 From noreply@sourceforge.net Fri Mar 23 17:40:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 09:40:23 -0800 Subject: [Patches] [ python-Patches-403667 ] Allow jython to work with test_socket. Message-ID: Patches item #403667, was updated on 2001-02-07 12:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403667&group_id=5470 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to work with test_socket. Initial Comment: The jython socket module does not have a "getservbyname" function. The patch makes this function optional. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 09:40 Message: Logged In: YES user_id=12800 Looks good to me. Applying to test_socket.py 1.19. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403667&group_id=5470 From noreply@sourceforge.net Fri Mar 23 17:54:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 09:54:25 -0800 Subject: [Patches] [ python-Patches-405853 ] Allow jython to use site.py Message-ID: Patches item #405853, was updated on 2001-03-04 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 >Category: library Group: None >Status: Closed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to use site.py Initial Comment: Change 1: Not all 'modules' in sys.modules have a sensible __file__ attribute. Some of our java package can have the __file__ attribute set to None. Change 2: In jython we have the jython license file in and the CPython license file in /Lib. By reversing the search sequence jython will find and show the jython license file before the CPython file. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 09:54 Message: Logged In: YES user_id=12800 Looks reasonable to me. Applying to site.py 1.26 ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-03-04 09:48 Message: Logged In: YES user_id=4201 Forgot to mark the upload checkbox. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405853&group_id=5470 From noreply@sourceforge.net Fri Mar 23 18:02:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 10:02:57 -0800 Subject: [Patches] [ python-Patches-403668 ] Allow jython to make temporary test modules Message-ID: Patches item #403668, was updated on 2001-02-07 12:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403668&group_id=5470 >Category: library Group: None >Status: Closed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to make temporary test modules Initial Comment: The @ char is not allowed in jython module names. Atleast one of the test uses the TESTFN name to create temporary modules. Use the $ instead when running under jython. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 10:02 Message: Logged In: YES user_id=12800 Based on CPython 2.1b2 version of the file, here's what I'm applying. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403668&group_id=5470 From noreply@sourceforge.net Fri Mar 23 18:04:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 10:04:41 -0800 Subject: [Patches] [ python-Patches-403668 ] Allow jython to make temporary test modules Message-ID: Patches item #403668, was updated on 2001-02-07 12:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403668&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to make temporary test modules Initial Comment: The @ char is not allowed in jython module names. Atleast one of the test uses the TESTFN name to create temporary modules. Use the $ instead when running under jython. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 10:04 Message: Logged In: YES user_id=12800 Patch file named 403668.txt is checked into test_support 1.21 for Python 2.1b2. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 10:02 Message: Logged In: YES user_id=12800 Based on CPython 2.1b2 version of the file, here's what I'm applying. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403668&group_id=5470 From noreply@sourceforge.net Fri Mar 23 18:55:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 10:55:08 -0800 Subject: [Patches] [ python-Patches-410890 ] Example of Python startup script Message-ID: Patches item #410890, was updated on 2001-03-23 10:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410890&group_id=5470 Category: demos and tools Group: None Status: Open Priority: 5 Submitted By: Itamar S.T. (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Example of Python startup script Initial Comment: Python has the ability to run a script at startup. However, this feature has no examples and I'm not sure how many people use it. I've written this script that (using readline): 1) Turns on auto-complete 2) Makes the command history saved between sessions 3) Is a good example of a startup script I think this should be in the examples or tools, so that Python packagers can integrate this on platforms where readline is available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410890&group_id=5470 From noreply@sourceforge.net Fri Mar 23 19:54:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 11:54:07 -0800 Subject: [Patches] [ python-Patches-405851 ] Allow jython to complete test_strftime Message-ID: Patches item #405851, was updated on 2001-03-04 09:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 Category: library Group: None Status: Open Priority: 3 Submitted By: Finn Bock (bckfnn) Assigned to: M.-A. Lemburg (lemburg) Summary: Allow jython to complete test_strftime Initial Comment: Java always eun with a national locale. As a result the default strings from the "time" module is national. This path will assign a US locale and allow a successful test even when running with a non-us computer. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-03-23 11:54 Message: Logged In: YES user_id=4201 Yes, Jython should have a locals _module but the locale categories makes little sense in java. Since a jython _locale module would be a very weak emulation of C I think it would be acceptable to make setlocale(LC_ALL, "C") mean java.util.Locale.US. OTOH your patch works fine for my test run of jython. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 09:25 Message: Logged In: YES user_id=12800 A couple of notes, then assignment back to Finn for determination. First, it seems to me that Jython ought to supply an _locale module for compatibility with CPython. That way, test_strftime.py could simply "import locale" and then do a locale.setlocale() without testing the platform. Second, it seems that Java has no "C" locale, but for CPython, the strftime tests require specifically "C" locale and not "en_US" locale (the latter of which breaks the tests). So, what is the right thing to do here? I'm attaching an alternative patch which ought to work today. Finn, please comment and I'll apply it for Python 2.1 final if it looks okay. Since Finn's not a CPython developer, I'm assigning the patch to MAL for a sanity check on the locale issues. MAL, feel free to assign back to me if my changes make sense. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 From noreply@sourceforge.net Fri Mar 23 20:23:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 12:23:59 -0800 Subject: [Patches] [ python-Patches-405851 ] Allow jython to complete test_strftime Message-ID: Patches item #405851, was updated on 2001-03-04 09:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 Category: library Group: None >Status: Closed Priority: 3 Submitted By: Finn Bock (bckfnn) Assigned to: M.-A. Lemburg (lemburg) Summary: Allow jython to complete test_strftime Initial Comment: Java always eun with a national locale. As a result the default strings from the "time" module is national. This path will assign a US locale and allow a successful test even when running with a non-us computer. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 12:23 Message: Logged In: YES user_id=12800 Okay, cool. In that case, I'll commit just this change for 2.1b2. test_strftime.py 1.25. Assigning away from MAL and closing (although he's more than welcome to comment :) ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-03-23 11:54 Message: Logged In: YES user_id=4201 Yes, Jython should have a locals _module but the locale categories makes little sense in java. Since a jython _locale module would be a very weak emulation of C I think it would be acceptable to make setlocale(LC_ALL, "C") mean java.util.Locale.US. OTOH your patch works fine for my test run of jython. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-23 09:25 Message: Logged In: YES user_id=12800 A couple of notes, then assignment back to Finn for determination. First, it seems to me that Jython ought to supply an _locale module for compatibility with CPython. That way, test_strftime.py could simply "import locale" and then do a locale.setlocale() without testing the platform. Second, it seems that Java has no "C" locale, but for CPython, the strftime tests require specifically "C" locale and not "en_US" locale (the latter of which breaks the tests). So, what is the right thing to do here? I'm attaching an alternative patch which ought to work today. Finn, please comment and I'll apply it for Python 2.1 final if it looks okay. Since Finn's not a CPython developer, I'm assigning the patch to MAL for a sanity check on the locale issues. MAL, feel free to assign back to me if my changes make sense. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405851&group_id=5470 From noreply@sourceforge.net Sat Mar 24 02:26:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 18:26:39 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was updated on 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- >Comment By: Paul Prescod (prescod) Date: 2001-03-23 18:26 Message: Logged In: YES user_id=31788 Well here's some incentive to check it in when you get a chance. I've got another patch that allows for pluggable compilers. parsermodule is used to build node objects to pass to Python code that replaces the compiler. Of course we may soon want pluggable parsers too... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-20 22:17 Message: Logged In: YES user_id=3066 I'll try to check in something similar tomorrow, when I've had a little time to sit on this now that I've actually read the comments. ;-) I don't think the included header is exactly right, but that's in part that I don't think the names are good (yes, I know they're mine!). ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:41 Message: Logged In: YES user_id=31788 (argh...the patch didn't show up) ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:39 Message: Logged In: YES user_id=31788 I'm adding the changes to parsermodule.c that need to be made so as not to duplicate the information in the new parsermodule.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From noreply@sourceforge.net Sat Mar 24 02:26:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Mar 2001 18:26:40 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was updated on 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- >Comment By: Paul Prescod (prescod) Date: 2001-03-23 18:26 Message: Logged In: YES user_id=31788 Well here's some incentive to check it in when you get a chance. I've got another patch that allows for pluggable compilers. parsermodule is used to build node objects to pass to Python code that replaces the compiler. Of course we may soon want pluggable parsers too... ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-23 18:26 Message: Logged In: YES user_id=31788 Well here's some incentive to check it in when you get a chance. I've got another patch that allows for pluggable compilers. parsermodule is used to build node objects to pass to Python code that replaces the compiler. Of course we may soon want pluggable parsers too... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-20 22:17 Message: Logged In: YES user_id=3066 I'll try to check in something similar tomorrow, when I've had a little time to sit on this now that I've actually read the comments. ;-) I don't think the included header is exactly right, but that's in part that I don't think the names are good (yes, I know they're mine!). ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:41 Message: Logged In: YES user_id=31788 (argh...the patch didn't show up) ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:39 Message: Logged In: YES user_id=31788 I'm adding the changes to parsermodule.c that need to be made so as not to duplicate the information in the new parsermodule.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From J Fri Mar 23 23:27:53 2001 From: J (J) Date: Fri, 23 Mar 2001 23:27:53 Subject: [Patches] Grow a Money Tree From Home! Message-ID: Dear Friends & Future Millionaire: AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time THANK'S TO THE COMPUTER AGE AND THE INTERNET ! ================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, New Jersey. =================================================== Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ====== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So do not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ========================================================== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the Internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ========================================================== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4 ... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGUREOUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ========================================================= REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ======================================================= Advertising on the net is very, very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and ad METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. =========== AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ==================================================== REPORT# 1: The Insider's Guide to Advertising for Free on the Net Order Report #1 from: J & D. Baugh P.O. Box 1602 Appleton, WI 54915 USA ________________________________________________________ REPORT # 2: The Insider's Guide to Sending Bulk e-mail on the Net Order Report # 2 from: A.L Hiltz 4076 Pine Tree Rd. Jonestone, PA 17038 USA _________________________________________________________________ REPORT # 3: Secret to Multilevel marketing on the net Order Report # 3 from : A. Smith P.O. Box 573072 Houston, TX 77257-3072 USA ____________________________________________________________ REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" Order Report # 4 from: C.J. Kalata P.O. Box 130157 Roseville, MN 55113-0002 USA ____________________________________________________________ REPORT #5: "How to Send Out 0ne Million e-mails for Free" Order Report # 5 from: R. B. Box. 21115, Grande Prairie Alberta, T8V-6W7 Canada ____________________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ====================================================== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ============ MORE TESTIMONIALS ================ "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ====================================================== ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ======================================================= ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ======================================================= ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanks to Internet.". Fred Dellaca, Westport, New Zealand ======================================================= ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. From noreply@sourceforge.net Sat Mar 24 16:13:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Mar 2001 08:13:18 -0800 Subject: [Patches] [ python-Patches-411055 ] Delete unimportable extensions Message-ID: Patches item #411055, was updated on 2001-03-24 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411055&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Delete unimportable extensions Initial Comment: If building an extension module succeeds, the module may still be unimportable, e.g. because not all symbols can be resolved. This patch arranges to import every module after it has been built, and removes those for which importing fails. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411055&group_id=5470 From noreply@sourceforge.net Sun Mar 25 08:30:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Mar 2001 00:30:41 -0800 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was updated on 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Sun Mar 25 14:22:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Mar 2001 06:22:45 -0800 Subject: [Patches] [ python-Patches-410046 ] asynchat: handle excessive response size Message-ID: Patches item #410046, was updated on 2001-03-20 08:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Doug Fort (dougfort) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat: handle excessive response size Initial Comment: When reading with a numeric terminator, asynchat assumes that if the server didn't send fewer bytes than requested, that it sent exactly the number of bytes requested. This is normally the case, but an overloaded server can return an error message that is larger than the number of bytes requested. When this happens asynchttp.handle_read() goes into a tight loop, returning an empty string for data and zero for a terminator. This patch raises an exception if the number of bytes returned exceeds the number requested. It's kind of an ugly fix, because asynchttp doesn't raise any other exceptions, and passes on those it catches to handle_error. However, this really is an exceptional case, and the results of not handling it are disastrous. ---------------------------------------------------------------------- >Comment By: Doug Fort (dougfort) Date: 2001-03-25 06:22 Message: Logged In: YES user_id=6399 I have discovered that there are real cases where the server sends back more bytes than requested: specifically in Trannsfer-mode: chunked. Here is a revised, much simpler patch that passes on the data. *** asynchat.py.original Tue Mar 20 10:43:01 2001 --- asynchat.py Sun Mar 25 09:13:56 2001 *************** *** 106,113 **** self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: --- 106,113 ---- self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() else: ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-03-20 08:36 Message: Logged In: YES user_id=6399 *** asynchat.pyTue Mar 20 11:11:58 2001 --- asynchat.py.originalTue Mar 20 10:43:01 2001 *************** *** 49,60 **** import socket import asyncore - class async_chat_exception(Exception): - def __init__(self, message): - self._message = message - def __str__(self): - return self._message - class async_chat (asyncore.dispatcher): """This is an abstract class. You must derive from this class, and add the two methods collect_incoming_data() and found_terminator()""" --- 49,54 ---- *************** *** 111,128 **** self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! elif lb == n: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() - else: - # if we got back more than we asked for, the server - # is badly confused - raise async_chat_exception( - "Unexpect response: requested %s bytes got %s. %s" % ( - n, lb, self.ac_in_buffer - )) else: # 3 cases: # 1) end of buffer matches terminator exactly: --- 105,115 ---- self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! else: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: # 3 cases: # 1) end of buffer matches terminator exactly: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 From noreply@sourceforge.net Sun Mar 25 17:58:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Mar 2001 09:58:24 -0800 Subject: [Patches] [ python-Patches-411188 ] Fix for #121965 ported to 2.0 Message-ID: Patches item #411188, was updated on 2001-03-25 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411188&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #121965 ported to 2.0 Initial Comment: This patch backports revs 2.21 and 2.22 of rangeobject.c to the 2.0 release branch, taking out the additional range member attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411188&group_id=5470 From noreply@sourceforge.net Sun Mar 25 18:01:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Mar 2001 10:01:33 -0800 Subject: [Patches] [ python-Patches-410709 ] Condition.wait() and KeyboardInterrupt Message-ID: Patches item #410709, was updated on 2001-03-22 21:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 Category: Modules Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait() and KeyboardInterrupt Initial Comment: >My problem is: Condition.wait() is not protected against >KeyboardInterrupt. Fix is below. > >Regards, >Oleg. > >----------------------------- >#python 2.0, threading.py: > >... >class _Condition(_Verbose): >... > def wait(self, timeout=None): >... > saved_state = self._release_save() ># line to be inserted > try: >... ># line to be inserted > finally: > self._acquire_restore(saved_state) > ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-03-25 10:01 Message: Logged In: YES user_id=21627 Is that something that is already fixed in 2.1? If not, the Group should be changed to None: 2.0.1 is for patches that are *only* meant for 2.0.1, i.e. who should not appear in later releases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 From noreply@sourceforge.net Sun Mar 25 18:53:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Mar 2001 10:53:47 -0800 Subject: [Patches] [ python-Patches-411191 ] Refcount bug in PyObject_Unicode Message-ID: Patches item #411191, was updated on 2001-03-25 10:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411191&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Refcount bug in PyObject_Unicode Initial Comment: This patch fixes what I think is a reference counting bug in the new function PyObject_Unicode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411191&group_id=5470 From noreply@sourceforge.net Sun Mar 25 19:17:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Mar 2001 11:17:31 -0800 Subject: [Patches] [ python-Patches-411191 ] Refcount bug in PyObject_Unicode Message-ID: Patches item #411191, was updated on 2001-03-25 10:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411191&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: M.-A. Lemburg (lemburg) Summary: Refcount bug in PyObject_Unicode Initial Comment: This patch fixes what I think is a reference counting bug in the new function PyObject_Unicode. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-03-25 11:17 Message: Logged In: YES user_id=38388 Checked in. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411191&group_id=5470 From noreply@sourceforge.net Sun Mar 25 21:32:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Mar 2001 13:32:37 -0800 Subject: [Patches] [ python-Patches-411213 ] Platform support: RISC OS, round 2 Message-ID: Patches item #411213, was updated on 2001-03-25 13:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411213&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: Platform support: RISC OS, round 2 Initial Comment: This patch should complete support for the RISC OS platform. Python should now compile out of the box on RISC OS. Readme.txt from the attached archive: ################################################################# Patches: Patches.txt contains following patches: (all changes are in #ifdef/#ifndef RISCOS clauses) timemodule.c: add support for a RISC OS implementation of sleep (to be found in new file RISCOS/sleep.c) main.c: replace 'getopt' by '_PyOS_GetOpt' sysmodule.c: bugfix: drop directory separator from end of sys.path[0] for RISC OS Lib/plat-riscos/riscospath.py: catch swi.swierror for empty file/pathnames ################################################################# Replacement file: RISCOS/Makefile: changes for 2.1b2; minimized whitespace to keep command line below 2048 character limit ################################################################# New files: RISCOS/sleep.c: Implement sleeping for RISC OS: int sleep(double delay) RISCOS/support/*: Support files for a complete Python under RISC OS Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411213&group_id=5470 From noreply@sourceforge.net Mon Mar 26 08:18:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Mar 2001 00:18:33 -0800 Subject: [Patches] [ python-Patches-410709 ] Condition.wait() and KeyboardInterrupt Message-ID: Patches item #410709, was updated on 2001-03-22 21:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 Category: Modules >Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait() and KeyboardInterrupt Initial Comment: >My problem is: Condition.wait() is not protected against >KeyboardInterrupt. Fix is below. > >Regards, >Oleg. > >----------------------------- >#python 2.0, threading.py: > >... >class _Condition(_Verbose): >... > def wait(self, timeout=None): >... > saved_state = self._release_save() ># line to be inserted > try: >... ># line to be inserted > finally: > self._acquire_restore(saved_state) > ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-25 10:01 Message: Logged In: YES user_id=21627 Is that something that is already fixed in 2.1? If not, the Group should be changed to None: 2.0.1 is for patches that are *only* meant for 2.0.1, i.e. who should not appear in later releases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 From noreply@sourceforge.net Mon Mar 26 15:59:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Mar 2001 07:59:19 -0800 Subject: [Patches] [ python-Patches-406248 ] Enable Weak References to Functions Message-ID: Patches item #406248, was updated on 2001-03-06 01:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406248&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Phil Thompson (rega39) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Enable Weak References to Functions Initial Comment: The patch enables weak references for functions, mainly useful for lambda functions. Without this patch it is possible for a PyQt programmer to write scripts that will seg fault the interpreter. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-26 07:59 Message: Logged In: YES user_id=3066 Included in Python 2.1 beta 2. Also added weakref support for method objects. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406248&group_id=5470 From noreply@sourceforge.net Mon Mar 26 16:00:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Mar 2001 08:00:34 -0800 Subject: [Patches] [ python-Patches-403789 ] Add support to zipfile for passing file-like objects Message-ID: Patches item #403789, was updated on 2001-02-14 04:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403789&group_id=5470 Category: library Group: None >Status: Closed Priority: 6 Submitted By: Itamar S.T. (itamar) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add support to zipfile for passing file-like objects Initial Comment: zipfile.ZipFile, in its current state, requires the user to pass a filename, which is then opened by ZipFile. I (and probably other people) require the ability to pass a file-like objects to ZipFile instead, e.g. have the zipped data stored in a StringIO object. This patch adds that ability. (Sorry, no unit testing included, and only lightly tested. But the changes are very straightforward.) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-26 08:00 Message: Logged In: YES user_id=3066 Checked in as Lib/zipfile.py revision 1.9 and Lib/test/test_zipfile.py revision 1.4. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-20 09:20 Message: Logged In: YES user_id=3066 Re-opened since the patch has been updated & Itamar reminded me that I was going to look at this. I expect to look at this & others tomorrow. ---------------------------------------------------------------------- Comment By: Itamar S.T. (itamar) Date: 2001-02-20 05:14 Message: As per Yhg1s's suggestion (he won't give me his real name - thomas?), I resubmitted everything as a patch. ---------------------------------------------------------------------- Comment By: Itamar S.T. (itamar) Date: 2001-02-20 04:46 Message: OK, here are some tests (I submitted the whole file, not a patch, since I basically rewrote it.). And I fixed zipfile.py based on your comments. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-19 11:46 Message: Please provide test cases for this. The tests should be added to Lib/test/test_zipfile.py. File-ness should probably be determined by checking if the object is a string or not (remember to test for a Unicode string as well!). Instead of catching an exception from checking for file.name, you can instead fetch the name using getattr(file, 'name', None) and not worry about exceptions; only the AttributeError you were actually trying to catch will be caught, and everything else will "do the right thing" instead of getting masked, as the current code does. I'll re-evaluate the patch when it gets updated at SF. (I think the idea is right -- there's no need to require a built-in file object.) ---------------------------------------------------------------------- Comment By: Itamar S.T. (itamar) Date: 2001-02-14 05:26 Message: Right now I detect file-like objects by doing hasattr(file, "read"). Doing hasattr(file, "write") might be better though, since for mode="w" ZipFiles, all you need are write() and tell() methods on the file-like object. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403789&group_id=5470 From noreply@sourceforge.net Mon Mar 26 17:14:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Mar 2001 09:14:52 -0800 Subject: [Patches] [ python-Patches-410267 ] some additional constants for termios Message-ID: Patches item #410267, was updated on 2001-03-21 01:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some additional constants for termios Initial Comment: This adds a pile of constants that were in my old plat-linux2/TERMIOS.py that aren't in the new termios.c. I'm not sure all of them have valid uses, but some of them certainly do (I noticed that TIOCGWINSZ was missing). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-26 09:14 Message: Logged In: YES user_id=3066 Checked in as Modules/termios.c revision 2.20. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:17 Message: Logged In: YES user_id=6656 CTRL isn't a constant; I should probably try compiling my patches before sending them in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 From noreply@sourceforge.net Mon Mar 26 23:41:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Mar 2001 15:41:29 -0800 Subject: [Patches] [ python-Patches-405102 ] os.py: fix docstring (make raw) Message-ID: Patches item #405102, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 Category: library Group: None >Status: Closed Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Ka-Ping Yee (ping) Summary: os.py: fix docstring (make raw) Initial Comment: The docstring for os contains sequences like '\r' that become real control characters; using r""" instead of """ makes the docstring read correctly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 22:58 Message: Logged In: YES user_id=6380 Ping, please just check this in! You're totally right that this needs fixing. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:02 Message: Logged In: YES user_id=11645 As usual, the file was not attached. Ping, can you please put it up somewhere, and give the URL in a comment? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405102&group_id=5470 From noreply@sourceforge.net Mon Mar 26 23:41:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Mar 2001 15:41:53 -0800 Subject: [Patches] [ python-Patches-405122 ] webbrowser fix Message-ID: Patches item #405122, was updated on 2001-03-01 06:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 Category: library Group: None >Status: Closed Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Ka-Ping Yee (ping) Summary: webbrowser fix Initial Comment: Put the word "Web" in the synopsis line. Remove the -no-about-splash option, as it prevents this module from working with Netscape 3. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 10:42 Message: Logged In: YES user_id=6380 Fixing ESR's finger error -- don't reject this yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405122&group_id=5470 From noreply@sourceforge.net Wed Mar 28 07:34:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Mar 2001 23:34:52 -0800 Subject: [Patches] [ python-Patches-411830 ] Misc/BeOS-setup.py Message-ID: Patches item #411830, was updated on 2001-03-27 23:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411830&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: Misc/BeOS-setup.py Initial Comment: Please put this file in Misc/BeOS-setup.py, for BeOS users who want to build all the modules. It's modified from version "1.37" to support BeOS build. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411830&group_id=5470 From noreply@sourceforge.net Wed Mar 28 08:14:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Mar 2001 00:14:58 -0800 Subject: [Patches] [ python-Patches-411834 ] Misc/BeOS-NOTES Message-ID: Patches item #411834, was updated on 2001-03-28 00:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411834&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: Misc/BeOS-NOTES Initial Comment: Please replace Misc/BeOS-NOTES. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411834&group_id=5470 From apec@chinanusa.com Thu Mar 29 01:36:10 2001 From: apec@chinanusa.com (APEC) Date: Wed, 28 Mar 2001 17:36:10 -0800 Subject: [Patches] An Invitation from the Asia-Pacific Rim Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_6C10_01C0B7AD.93D0E520 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit Aiming at Asia-Pacific Market? Here's your one and only chance this year to target 21 developed and developing member economies in the Asia-Pacific rim . Industrial Science and Technology Cooperation Conference and Exhibition September 21 - 25, 2001 Suzhou, China An hour's drive from Shanghai, the biggest city in China Who Should Attend * Technology-oriented companies who want to demonstrate advanced technologies or to seek joint ventures * Venture capitalists and other investors who want to identify promising high-tech companies and investment opportunities * Entrepreneurs who are seeking market expansion to the Asia-Pacific region Best Chance to Showcase Technologies * Exhibition & transaction of high technology & hi-tech products. * Bid for technological cooperation. * Discussions & negotiations on technological transaction and cooperation. * APEC forum on science and technology. All the Opportunities! * Technomart is endorsed by APEC's 21 member economies that had a combined Gross Domestic Product of over US$18 trillion in 1999 and 43.85 percent of global trade. * In Technomart III, attendees included 1,000+ hi-tech exhibitors and recorded 37,000 visitors. * In Technomart III, over 5,000 business negotiations occurred, involving trade in excess of about US$ 100 million over the course of the five-day event. * Direct connection to China market. Service Center * Technomart representation * Exhibition Booth & Expense * Booth arrangements and allocation * Transportation * Hotels * Sourcing/manufacturers visits * On-site public relation facilitation, media coverage * Collateral translation * Escort interpretation * Leisure touring in Suzhou and its vacinities Key Technological Areas * Biotechnology * Environmental and cleaner production technologies * Communication * Information technologies / electronics * Advanced materials * Mechatronics * Transportation * Resource management technology * Energy * Sustainable agriculture * Emergency preparedness and climate prediction * Exploitation of natural resources For more information about the upcoming APEC Technomart IV, please visit: http://www.apec2001.org For inquiring a brochure, please visit: http://www.apec2001.org/apec_register.asp For Technomart IV services, please visit: http://www.apec2001.org/apec_serve.asp For exhibition booth information, please visit: http://www.apec2001.org/apec_booth.asp For on-line registration information, please click: For further questions, please email us at apec@CHINAnUSA.com or call Jessica Pan at (510) 497-8783. _____ CHINAnUSA.com is proud to represent APEC Technomart IV committee here in the US to work closely with you. It is our pleasure to assist you in every aspect for the most beneficial trade show. The past Technomart initiated trillions of transactions. Register today ! We look forward to your participation and seeing you in Suzhou, China. Authorized representative of APEC Technomart IV Unsubscribe: If you received this message in error or wish to unsubscribe from this subject, just click here: Click here. Or you can reply to this email with 'Unsubscribe' as subject title. All trademarks are the property of their respective owners (C)2001 All rights reserved. ------=_NextPart_000_6C10_01C0B7AD.93D0E520 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Aiming at=20 Asia-Pacific Market?
Here's your one=20 and only chance this year to target
21 developed = and developing member economies in the Asia-Pacific=20 rim.

  
 Industrial Science and Technology=20 Cooperation
 Conference and = Exhibition
 September 21 - 25, 2001
 Suzhou,=20 China

 An = hour's drive from=20 Shanghai, the biggest city in China =
Who Should Attend
  • Technology-oriented=20 companies who want to     demonstrate = advanced=20 technologies or to seek     joint=20 ventures
  • Venture = capitalists and=20 other investors who     want to = identify=20 promising high-tech     companies and=20 investment opportunities
  • Entrepreneurs who are=20 seeking market     expansion to the=20 Asia-Pacific region
    •  
    Best Chance to Showcase = Technologies
  • Exhibition = &=20 transaction of high technology &=20     hi-tech = products.
  • Bid for = technological=20 cooperation.
  • Discussions &=20 negotiations on technological =     transaction=20 and cooperation.
  • APEC forum = on science=20 and technology.
    •  
    All the Opportunities!
  • Technomart = is endorsed=20 by APEC's 21     member economies that = had a=20 combined     Gross Domestic Product of = over=20 US$18 trillion     in 1999 and 43.85 = percent=20 of global trade.
  • In = Technomart III,=20 attendees included 1,000+     hi-tech=20 exhibitors and recorded 37,000 = visitors.
  • In = Technomart III, over=20 5,000 business     negotiations = occurred,=20 involving trade in     excess of about = US$ 100=20 million over the     course of the = five-day=20 event.
  • Direct = connection to=20 China market.
    •  
    Service Center
  • Technomart = representation
  • Exhibition = Booth=20 & Expense
  • Booth = arrangements and=20 allocation
  • Transportation
  • Hotels
  • Sourcing/manufacturers=20 visits
  • On-site = public relation=20 facilitation, media=20     coverage
  • Collateral = translation
  • Escort=20 interpretation
  • Leisure = touring in=20 Suzhou and its vacinities
    •  
    =
    Key Technological Areas
  • Biotechnology
  • Environmental and=20 cleaner production=20     technologies
  • Communication
  • Information technologies=20 / electronics
  • Advanced=20 materials
  • Mechatronics
  • Transportation
  • Resource = management=20 technology
  • Energy
  • Sustainable=20 agriculture
  • Emergency = preparedness=20 and climate =     prediction
  • Exploitation of natural=20 resources
    •  
    <= /TR>
     For more=20 information about the upcoming APEC Technomart IV, please=20 visit:
    http://www.apec2001.org
     For inquiring=20 a brochure, please visit:
    http://www.apec2001.or= g/apec_register.asp
     For Technomart=20 IV services, please visit:
    http://www.apec2001.org/a= pec_serve.asp
     For exhibition=20 booth information, please visit:
    http://www.apec2001.org/a= pec_booth.asp
     For on-line registration information, please click:  
    =20 For further questions, please email us at apec@CHINAnUSA.com or call = Jessica Pan at (510) 497-8783.
    ------=_NextPart_000_6C10_01C0B7AD.93D0E520-- From noreply@sourceforge.net Thu Mar 29 15:21:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Mar 2001 07:21:21 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was updated on 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-29 07:21 Message: Logged In: YES user_id=3066 Mike: you suggested that you could also provide some of the material from your IPC9 paper to flesh out these sections -- do you have time to do the integration, or would someone else need to do it? I see a lot of Tcl code in the paper -- would this be converted to Python as examples? Thanks! ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Thu Mar 29 16:55:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Mar 2001 08:55:32 -0800 Subject: [Patches] [ python-Patches-412229 ] runtime RTLD_NOW control via sys Message-ID: Patches item #412229, was updated on 2001-03-29 08:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412229&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Bram Stolk (bram) Assigned to: Nobody/Anonymous (nobody) Summary: runtime RTLD_NOW control via sys Initial Comment: This patch enables runtime control over the RTLD_NOW flag, which can be used to do lazy symbol resolving when loading a shared lib. It's an extention to the sys module: sys.setlazysymresolve(0|1) The patch is against the latest CVS code, and was generated by 'cvs diff'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412229&group_id=5470 From noreply@sourceforge.net Thu Mar 29 17:28:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Mar 2001 09:28:27 -0800 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was updated on 2001-03-22 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Category: Windows Group: None Status: Open Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Tim Peters (tim_one) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-29 09:28 Message: Logged In: YES user_id=6380 Tim, wasn't this supposed to go into 2.1b2? Did it? Can it go into 2.1final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-22 13:35 Message: Logged In: YES user_id=31435 /F, can you add a doc patch (for os.statvfs) that says enough so that a Windows user has some chance of guessing what this function returns? BTW, I have no problem w/ returning zeroes instead of Nones. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply@sourceforge.net Thu Mar 29 21:42:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Mar 2001 13:42:06 -0800 Subject: [Patches] [ python-Patches-411213 ] Platform support: RISC OS, round 2 Message-ID: Patches item #411213, was updated on 2001-03-25 13:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411213&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: Platform support: RISC OS, round 2 Initial Comment: This patch should complete support for the RISC OS platform. Python should now compile out of the box on RISC OS. Readme.txt from the attached archive: ################################################################# Patches: Patches.txt contains following patches: (all changes are in #ifdef/#ifndef RISCOS clauses) timemodule.c: add support for a RISC OS implementation of sleep (to be found in new file RISCOS/sleep.c) main.c: replace 'getopt' by '_PyOS_GetOpt' sysmodule.c: bugfix: drop directory separator from end of sys.path[0] for RISC OS Lib/plat-riscos/riscospath.py: catch swi.swierror for empty file/pathnames ################################################################# Replacement file: RISCOS/Makefile: changes for 2.1b2; minimized whitespace to keep command line below 2048 character limit ################################################################# New files: RISCOS/sleep.c: Implement sleeping for RISC OS: int sleep(double delay) RISCOS/support/*: Support files for a complete Python under RISC OS Thanks. ---------------------------------------------------------------------- >Comment By: Dietmar Schwertberger (dschwertberger) Date: 2001-03-29 13:42 Message: Logged In: YES user_id=86612 Please ignore the first archive. Riscos2.zip contains improved handling for RISC OS specific command line option. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411213&group_id=5470 From noreply@sourceforge.net Fri Mar 30 04:13:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Mar 2001 20:13:50 -0800 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was updated on 2001-03-22 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Category: Windows Group: None Status: Open Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Guido van Rossum (gvanrossum) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-03-29 20:13 Message: Logged In: YES user_id=31435 No, it did not go in. I asked for a doc patch first so I wouldn't have to pee away time trying to guess what it does. Now I've peed away the time, and I don't like it. Here's what it returns on my home desktop box (Win98SE, 20Gb drive): >>> os.statvfs("c:\") # argument is very touchy (32768, 32768, 65526, 65526, 65526, 0, 0, 0, 0, 1024) >>> *Nothing* there makes sense, except for the last "max path" result. Even the "block size" is wrong (the FAT32 fs on this box uses 16Kb clusters, not 32Kb). Digging into the MS docs, """The GetDiskFreeSpace function returns incorrect values for volumes that are larger than 2 gigabytes""" and """Even on volumes that are smaller than 2 gigabytes, the values stored into *lpSectorsPerCluster, *lpNumberOfFreeClusters, and *lpTotalNumberOfClusters values may be incorrect""" under Win95, and, to judge from my desktop box, it appears useless under the latest flavor of Win98 too. The function the patch uses is obsolete, and a ...Ex version is recommended in its place, which """returns correct values for all volumes, including those that are greater than 2 gigabytes""" BUT, *that* function isn't available under the original Win95, only under Win95 OSR2 and later. In addition, that function only returns number of bytes total and free (as 64 bit unsigned ints), nothing about block size, # clusters, etc. (OTOH, total bytes is free is what people asked for! I don't recall anyone asking for a statvfs() clone) So bouncing back to you: how much time do you want me to devote to this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-29 09:28 Message: Logged In: YES user_id=6380 Tim, wasn't this supposed to go into 2.1b2? Did it? Can it go into 2.1final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-22 13:35 Message: Logged In: YES user_id=31435 /F, can you add a doc patch (for os.statvfs) that says enough so that a Windows user has some chance of guessing what this function returns? BTW, I have no problem w/ returning zeroes instead of Nones. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply@sourceforge.net Fri Mar 30 12:22:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Mar 2001 04:22:33 -0800 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was updated on 2001-03-22 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Category: Windows Group: None Status: Open >Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-30 04:22 Message: Logged In: YES user_id=6380 Thanks for the investigation, Tim! Bouncing it back to Fredrik and lowered priority. I certainly don't want to spend a lot of time on it; I believe that the flamewar that started this was ill-advised anyway. Finding out free space is hard; too bad. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-29 20:13 Message: Logged In: YES user_id=31435 No, it did not go in. I asked for a doc patch first so I wouldn't have to pee away time trying to guess what it does. Now I've peed away the time, and I don't like it. Here's what it returns on my home desktop box (Win98SE, 20Gb drive): >>> os.statvfs("c:\") # argument is very touchy (32768, 32768, 65526, 65526, 65526, 0, 0, 0, 0, 1024) >>> *Nothing* there makes sense, except for the last "max path" result. Even the "block size" is wrong (the FAT32 fs on this box uses 16Kb clusters, not 32Kb). Digging into the MS docs, """The GetDiskFreeSpace function returns incorrect values for volumes that are larger than 2 gigabytes""" and """Even on volumes that are smaller than 2 gigabytes, the values stored into *lpSectorsPerCluster, *lpNumberOfFreeClusters, and *lpTotalNumberOfClusters values may be incorrect""" under Win95, and, to judge from my desktop box, it appears useless under the latest flavor of Win98 too. The function the patch uses is obsolete, and a ...Ex version is recommended in its place, which """returns correct values for all volumes, including those that are greater than 2 gigabytes""" BUT, *that* function isn't available under the original Win95, only under Win95 OSR2 and later. In addition, that function only returns number of bytes total and free (as 64 bit unsigned ints), nothing about block size, # clusters, etc. (OTOH, total bytes is free is what people asked for! I don't recall anyone asking for a statvfs() clone) So bouncing back to you: how much time do you want me to devote to this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-29 09:28 Message: Logged In: YES user_id=6380 Tim, wasn't this supposed to go into 2.1b2? Did it? Can it go into 2.1final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-22 13:35 Message: Logged In: YES user_id=31435 /F, can you add a doc patch (for os.statvfs) that says enough so that a Windows user has some chance of guessing what this function returns? BTW, I have no problem w/ returning zeroes instead of Nones. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply@sourceforge.net Fri Mar 30 20:06:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Mar 2001 12:06:02 -0800 Subject: [Patches] [ python-Patches-412553 ] fix linuxaudiodev handling of EAGAIN Message-ID: Patches item #412553, was updated on 2001-03-30 12:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Christopher Lee (clee) Assigned to: Nobody/Anonymous (nobody) Summary: fix linuxaudiodev handling of EAGAIN Initial Comment: The linuxaudiodev write method uses a non-blocking call to write data to the sound device. When the buffer for this device is full, it returns the EAGAIN error. The current linuxaudiodev lad_write code returns this as an error and terminates the write. This patch detects the EAGAIN errno and retries the write. It allows the test_linuxaudiodev.py to be heard under my system (i686 linux 2.4.2 and 2.4.3) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 From noreply@sourceforge.net Sat Mar 31 08:34:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 31 Mar 2001 00:34:33 -0800 Subject: [Patches] [ python-Patches-412672 ] Backport of revs 2.32, 2.34 of pyexpat Message-ID: Patches item #412672, was updated on 2001-03-31 00:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412672&group_id=5470 Category: XML Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Moshe Zadka (moshez) Summary: Backport of revs 2.32, 2.34 of pyexpat Initial Comment: This patch extracts the memory management fixes from these patches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412672&group_id=5470 From noreply@sourceforge.net Sat Mar 31 08:35:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 31 Mar 2001 00:35:05 -0800 Subject: [Patches] [ python-Patches-411188 ] Fix for #121965 ported to 2.0 Message-ID: Patches item #411188, was updated on 2001-03-25 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411188&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Moshe Zadka (moshez) Summary: Fix for #121965 ported to 2.0 Initial Comment: This patch backports revs 2.21 and 2.22 of rangeobject.c to the 2.0 release branch, taking out the additional range member attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411188&group_id=5470 From noreply@sourceforge.net Sat Mar 31 14:39:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 31 Mar 2001 06:39:05 -0800 Subject: [Patches] [ python-Patches-412553 ] fix linuxaudiodev handling of EAGAIN Message-ID: Patches item #412553, was updated on 2001-03-30 12:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Christopher Lee (clee) Assigned to: Nobody/Anonymous (nobody) Summary: fix linuxaudiodev handling of EAGAIN Initial Comment: The linuxaudiodev write method uses a non-blocking call to write data to the sound device. When the buffer for this device is full, it returns the EAGAIN error. The current linuxaudiodev lad_write code returns this as an error and terminates the write. This patch detects the EAGAIN errno and retries the write. It allows the test_linuxaudiodev.py to be heard under my system (i686 linux 2.4.2 and 2.4.3) ---------------------------------------------------------------------- >Comment By: Christopher Lee (clee) Date: 2001-03-31 06:39 Message: Logged In: YES user_id=1426 I'm deleting the first patch because it is wasteful of CPU cycles. The updated patch uses select to wait for the device to become available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 From noreply@sourceforge.net Sat Mar 31 14:44:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 31 Mar 2001 06:44:39 -0800 Subject: [Patches] [ python-Patches-412553 ] fix linuxaudiodev handling of EAGAIN Message-ID: Patches item #412553, was updated on 2001-03-30 12:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Christopher Lee (clee) Assigned to: Nobody/Anonymous (nobody) Summary: fix linuxaudiodev handling of EAGAIN Initial Comment: The linuxaudiodev write method uses a non-blocking call to write data to the sound device. When the buffer for this device is full, it returns the EAGAIN error. The current linuxaudiodev lad_write code returns this as an error and terminates the write. This patch detects the EAGAIN errno and retries the write. It allows the test_linuxaudiodev.py to be heard under my system (i686 linux 2.4.2 and 2.4.3) ---------------------------------------------------------------------- >Comment By: Christopher Lee (clee) Date: 2001-03-31 06:44 Message: Logged In: YES user_id=1426 I couldn't delete the first patch. Instead I'm simply uploading the second version based upon select(). Patch created by going to the src/Modules/ directory and doing a: cvs diff -c linuxaudiodev.c ---------------------------------------------------------------------- Comment By: Christopher Lee (clee) Date: 2001-03-31 06:39 Message: Logged In: YES user_id=1426 I'm deleting the first patch because it is wasteful of CPU cycles. The updated patch uses select to wait for the device to become available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470
    CHINAnUSA.com is proud to represent APEC Technomart = IV=20 committee here in the US to work closely with you. It is our = pleasure to=20 assist you in every aspect for the most beneficial trade=20 show.

    The past Technomart initiated trillions of=20 transactions.    Register today! =
    We look=20 forward to your participation and seeing you in Suzhou,=20 China.

    Authorized representative of APEC Technomart=20 IV

    Unsubscribe:
    =
    If you = received this message in error or wish to unsubscribe from this subject, = just click here: Click = here.
    Or you can reply to this email with = 'Unsubscribe' as subject = title.


    All trademarks are the property of their respective = owners (C)2001 All rights reserved. =